zookeeper 崩溃恢复过程中两个关键性问题
Q1：leader 提交事务 A 后崩溃，follower 没有收到提交事务 A 的消息，再次选举 leader 时如何确保事务 A 被应用？
A1：既然 leader 已经在本地提交了事务 A，那么说明事务 A 肯定已经经过了多数 follower 的确认，即多数 follower 上都有事务 A 的记录，leader 崩溃后，重新选举出的新 leader 肯定包含未提交的事务 A，因为事务 A 的事务 ID 最大，新 leader 会继续提交事务 A。
Q2：leader 在还未将事务 B 广播到集群中时崩溃，在重新选举 leader 并在旧 leader 恢复正常后如何处理事务 B？
A2：事务 B 将会被删除，不会被提交。leader 在接收到一个请求，并将其转化为事务 B 后崩溃，此时还没有将事务 B 广播到集群中，即此事务只存在于 leader 机器上，经过新一轮的 leader 选举后，旧 leader 恢复正常并加入集群，此时会发现事务 B 的事务 ID 所使用的 epoch 号与新 leader 的对不上，那么事务 B 就会被删除。
应用场景
把握好 zookeeper 的主要特性就可以将其应用在多种多样的场景下。主要特性如下：
- 节点
- 树结构
- 持久节点
- 持久顺序节点
- 临时节点
- 临时顺序节点
- 节点只能被注册一次
- watcher
在《从 Paxos 到 Zookeeper》一书中提到的应用场景以及我认为场景所应用到的主要特性如下：
- 数据发布/订阅（配置中心）
- watcher
- DNS 服务负载均衡
- 树结构
- watcher
- 命名服务
- 持久顺序节点
- 分布式协调/通知
- 临时节点
- 临时顺序节点
- watcher
- 集群管理
- 临时节点
- watcher
- Master 选举
- 节点只能被注册一次
- watcher
- 分布式锁
- 节点只能被注册一次（排他锁/写锁/独占锁）
- 临时顺序节点（共享锁/读锁）
- watcher
- 分布式队列
- 临时顺序节点
- watcher