分布式理论+ZooKeeper相关概念总结

一、分布式理论、算法、协议

1. CAP理论 CAP分别代表Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）

• 一致性：所有数据访问同一份最新的数据
• 可用性：非故障节点在合理时间内返回合理的响应
• 分区容错性：分布式系统出现网络分区时，仍能对外提供服务

如果系统出现分区，需要考虑选择CP还是AP，没出现分区的话，需要考虑怎么保证CA

1. BASE理论 BASE 是 Basically Available（基本可用）、Soft-state（软状态） 和 Eventually Consistent（最终一致性） ，基于CAP定理演化而来

核心思想
即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。即牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

• 基本可用：在分布式系统出现故障时，允许损失部分可用性
• 软状态：允许系统数据出现中间状态，即不一致性
• 最终一致性：所有数据副本在经过一段时间同步后，能达到最终一致性

最终一致性实现方案

• 读时修复：读取数据时，检测数据的不一致，
• 写时修复：写入数据时，检测数据的不一致
• 异步修复：定时对账，检测数据副本的一致性

1. Paxos算法（分布式系统共识算法）

• 包含basic和multi两个部分
• Raft算法、ZAB算法、Fast Paxos算法都是基于此改进而来

算法流程（Basic）

1. Raft算法
2. Gossip算法

二、ZooKeeper相关概念

1. ZooKeeper概览 ZooKeeper是一个开源的分布式协调服务，其设计目标是将复杂且容易出错的分布式一致性服务封装起来，构成可靠的原语集提供给用户使用，如：数据发布/订阅、负载均衡、Master选举、集群管理、分布式协调/通知、分布式锁、分布式队列
2. ZooKeeper特点

• 顺序一致性：同一个客户端的请求，会严格按照顺序应用
• 原子性：所有请求结果在所有机器上的应用情况是一致的
• 单一系统映像：客户端连接不同的服务端看到的数据都是一致的
• 可靠性：请求带来的改变会被持久化
• 实时性：每个客户端的视图都是最新的
• 集群部署
• 高可用

1. 重要概念Znode（数据节点） 是ZooKeeper中存储数据的最小单元，通常分为4类：

• 持久节点：一旦创建就一直存在，直到被删除
• 临时节点：生命周期与客户端session绑定，会话消失则节点消失，临时节点只能为叶子结点，不能创建子节点
• 持久顺序节点：为名字具有顺序性的持久节点，如/node1/app0001
• 临时顺序节点：为名字具有顺序性的临时节点

每个Znode由两部分组成

• stat：状态信息，包含事务id、节点创建时间、子节点个数等
• data：节点存放数据的具体内容

Watcher（事件监听器）
zookeeper允许用户在节点上注册watcher，在某些特定事件触发时，zookeeper会将事件通知到客户端上。

会话（session）
服务器与客户端之间的一个tcp长连接，客户端可以通过心跳检测与服务器保持有效的会话，

zookeeper集群角色

• Leader：为客户端提供读写功能，负责投票的发起的决议，更新系统状态；
• Follower：为客户端提供读功能，写请求则转发到leader，参与选举过程中的投票；
• Observer：为客户端提供读功能，写请求则转发给 Leader。不参与选举过程中的投票，也不参与“过半写成功”策略，在不影响写性能的情况下提升集群的读性能。

Leader选举过程

• leader election：节点在一开始都处于选举阶段，获得超过半数投票的节点变为准leader
• discovery：follower和准leader通信，同步follower最近接收的事务提议
• Synchronization：利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本，同步完成之后准 leader 才会成为真正的 leader
• Broadcast：ZooKeeper 集群正式对外提供事务服务， leader 可以进行消息广播。同时如果有新的节点加入，需要对新节点进行同步。

服务器状态

• Looking：寻找leader
• Leading：leader状态
• Following：follower状态
• Observing：Obeserver状态

为什么最好奇数台
2n-1和2n的容忍度是一样的，都允许挂n-1台

过半机制防止脑裂
如果没有过半机制的话，当出现网络分区时，会选举出多个leader，网络恢复时存在一致性问题

ZAB协议
是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性

ZAB包含两种模式

• 崩溃恢复：在启动过程中，或是当 Leader出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader。当选举产生了新的 Leader ，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。
• 消息广播：当集群中已经有过半的 Follower 完成了和 Leader 的状态同步，那么整个服务框架就可以进入消息广播模式了。 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。

zookeeper典型应用场景

• 选主 由于zookeeper的强一致性，能够很好地保证高并发场景下创建节点的唯一性，因此可以让多个客户端创建同一个临时节点，创建成功的为master；如果master挂了，临时节点生命周期终止，可以创建watcher监听临时节点父节点的子节点个数，发生变化则触发回调函数重新选举
• 数据发布/订阅 客户端向服务端注册节点，一旦数据发生变更，服务端会向监听该节点的客户端发送watcher事件通知，客户端收到消息后，主动获取服务端最新数据
• 负载均衡 基于临时节点实现，每个server作为客户端连接zookeeper，并用server的地址信息创建临时节点，当server集群被调用时，首先获取该目录下所有节点（所有server地址），然后再根据负载均衡策略进行转发
• 分布式锁

基于临时顺序节点和watcher实现：

获取锁：在持久节点下创建临时顺序节点，创建成功后，判断是否为最小，是的话获取成功，不是的话在前一个节点注册事件监听器
释放锁：完成业务流程或者发生故障后，该节点被删除，即释放锁

可重入锁：

直接在客户端判断当前线程有没有获取锁

读写锁：

共享锁：没有比自己小的写请求，则可以获取，监听最后一个写请求
排他锁：没有任何比自己小的请求，则可以获取，监听最后一个请求

• 命名服务 可以用zk中唯一的节点全路径作为对象名称
• 集群管理和注册中心 临时节点+watcher