死锁、脑裂、惊群效应是分布式锁的核心问题，你知道它们各自是怎么一回事吗？ZooKeeper 和 etcd 是如何应对这些问题的呢？ 死锁：加锁后由于没有添加锁的过期时间或者锁的时间设置过长，服务异常crash或者服务执行后漏执行释放锁操作，导致锁长时间没有释放 脑裂：分布式体系结构中的集中式结构（也称为 Master/Slave 架构），一个Master节点多个Slave节点，所有的请求数据处理必须先经过Master中央服务器，由Master统一进行资源和任务调度，中央服务器根据这些信息，将任务下达给节点服务器，节点服务器执行任务，并将结果反馈给中央服务器。脑裂是在某些特殊条件下，如主备切换，Slave在与Master的网络出现故障的时候，Slave会认为Master已经故障，从而成为新的master，而原来的master也没有卸任，从而导致存在两个Master在对外服务，存在多master会导致共享资源的互斥性遭到破坏，出现资源争抢，数据不一致等问题 惊群效应：指多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），如果等待的这个事件发生，那么他就会唤醒等待的所有进程（或者线程），但是最终却只能有一个进程（线程）获得这个时间的“控制权”，对该事件进行处理，而其他进程（线程）获取“控制权”失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群效应。（当你往一群鸽子中间扔一块食物，虽然最终只有一个鸽子抢到食物，但所有鸽子都会被惊动来争夺，没有抢到食物的鸽子只好回去继续睡觉， 等待下一块食物到来。这样，每扔一块食物，都会惊动所有的鸽子，即为惊群。） etcd如何避免死锁：利用Lease的活性检测机制，它提供了检测各个客户端存活的能力。你的业务 client 需定期向 etcd 服务发送"特殊心跳"汇报健康状态，若你未正常发送心跳，并超过和 etcd 服务约定的最大存活时间后，就会被 etcd 服务移除此 Lease 和其关联的数据。通过 Lease 机制就优雅地解决了 client 出现 crash 故障、client 与 etcd 集群网络出现隔离等各类故障场景下的死锁问题。一旦超过 Lease TTL，它就能自动被释放，确保了其他 client 在 TTL 过期后能正常申请锁，保障了业务的可用性。 etcd如何避免集群脑裂：在leader选举上采用了过半机制，即得到一半以上的follow才能成为leader，且新leader就任后旧leader必须卸任，所以etcd不存在脑裂问题 etcd如何避免惊群效应：mutex，通过 Watch 机制各自监听 prefix 相同，revision 比自己小的 key，因为只有 revision 比自己小的 key 释放锁，才能有机会，获得锁