1. Zookeeper 理论

分布式中遇到的问题：

1. 网络分区
   由于网络延迟导致的分布式节点中只有部分能够进行正常通信，另一部分则不能，我们将这种现象叫做网络分区，俗称“脑裂”，当网络分区出现时会存在局部小集群，小集群完成了原来需要全部节点参与的分布式事务请求，这对分布式一致性挑战很大。
2. 三态
   成功、失败、超时。当出现超时现象时，就无法确定请求是否被处理成功。
3. 通信异常
4. 节点故障

分布式特点：

1. 分布性
2. 对等性
3. 并发性
4. 缺乏全局时钟
5. 故障随时会发生

1. 一致性（C）
   数据在分布式环境下的多个副本之间能否保持一致性，这里的一致性更多是指强一致性。
2. 可用性(A)
   对于用户的每一个请求，都希望在有限的时间内返回结果，有限的时间指的是系统设计的响应时间，返回结果是一个正常的要么成功要么失败的结果，而不是一个用户看不懂的结果。
3. 分区容错性（P）
   在遇到网络分区的时候，仍然需要保证提供一致性的可用服务。比如不同机房的部署结构，机房之间通信异常。

一个分布式系统无法同时满足上述三个需求，只能满足其中两项：

1. 放弃P
   避免出现分区容错，只能把数据丢到一个分布式节点上，放弃P同时也放弃了系统可扩展性。
2. 放弃A
   当遇到系统故障，系统需要等待一定时间，在这段时间内系统是不可用的。
3. 放弃C
   放弃一致性，不是指系统不要一致性，不要一致性的系统是没有意义的，放弃C指的是不要求强一致性，需要最终一致性，这就需要有一个时间窗口，这个时间窗口指的是系统需要多久才能达到最终一致性。

P是一个最基本的要求，我们只要在C和A中找平衡。

BASE是 Basically Available（基本可用），Soft state（软状态）和Eventually consistent（最终一致性）的简写。BASE是对CAP中一致性和可用性的一个权衡，核心思想是即使无法做到强一致性，但系统要达到最终一致性。

1. 基本可用
   允许损失部分可用性，不等价于系统不可用。具体损失表现在：响应时间上的损失，功能上的损失（峰值并发时可能会引导到一个降级的页面）。
2. 弱状态
   即允许数据存在中间状态，允许数据在不同节点进行数据同步时存在延时。
3. 最终一致性
   系统间的所有数据副本，在经过一段时间同步后，最终能够达到一致性，不需要实时一致性。

当一个事务操作需要跨越多个分布式节点时，为了保持事务处理的ACID特性，就需要引入一个“协调者”的组件来统一调度所有分布式节点的执行，这些被调度的分布式节点则称为“参与者”，协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正提交。
基于这种思想，衍生出了二阶段和三阶段提交协议。

2PC 和 3PC 两者都无法彻底解决分布式一致性问题。

目前绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的。
二阶段提交协议是将事务的提交过程分成两个阶段来进行处理：

1. 提交事务请求。也被称为“投票阶段”，参与者投票表明是否需要继续执行接下去的事务提交操作。
2. 执行事务提交，协调者会根据各参与者反馈的情况来决定最终是否进行事务提交。

优缺点：

1. 优点：原理简单，实现方便
2. 缺点：同步阻塞、单点问题、数据不一致
   同步阻塞：各参与者都需要等待其他参与者的响应，期间什么都做不了。
   单点问题：协调者有明显的单点问题，非常容易挂掉。
   数据不一致：协调者发送部分节点commit指令后挂了，数据出现不一致。

3PC 是 2PC的改进版。
分为 3 个阶段：

1. CanCommit
2. PreCommit
3. doCommit

与两阶段提交不同的是，三阶段提交有两个改动点：

1. 引入超时机制。同时在协调者和参与者中都引入超时机制。
2. 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。

3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

zookeeper 是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

Leader：Leader 为客户端提供读写服务
Follower：Follower 为客户端提供读服务
Observer：Observer 为客户端提供读服务，不参与选举 Leader，不参与事务投票，不影响写性能提高集群的读性能。

Session 是指客户端会话，是客户端连接服务端的一个 TCP 长连接。服务端的 Watch 事件通知也是通过该 TCP 连接。

Zookeeper 将所有的数据存储在内存中，数据模型是一棵树（Znode Tree），由斜杆进行分割的路径，就是一个Znode，每个 Znode 上都会保存自己的数据内容，同时还会保存一些列的属性信息。
在 Zookeeper 中，Znode 分为持久节点和临时节点。
持久节点是指一旦创建，除非主动删除，否则这个 Znode 会一直在 Zookeeper 中；临时节点它的生命周期是跟会话绑定，一旦客户端会话失效，临时节点将会删除，同时临时节点不能有子节点。
另外，Zookeeper 可以为每个节点添加 SEQUENTIAL 属性，一旦有这个属性，那么节点就是一个有序节点。

Zookeeper 会对每一个 Znode 维护一个 Stat 的数据结构，Stat 中记录了 Znode 的三个数据版本，分别是 version（当前Znode的版本）、cversion（当前 Znode 子节点的版本）和 aversion（当前 Znode 的ACL版本）。

Zookeeper 允许用户在指定节点上注册 Watcher，并且在一些特定事件触发的时候，Zookeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper 实现分布式协调服务的重要特性。
Watcher 是一次性的。