分布式环境的特点：并发、无序
分布式面临的问题：
网络通信
网络分区(脑裂)：当网络发生异常导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式架构的所有节点，只有部分节点能够正常通信
分布式事务：ACID(原子性、一致性、隔离性、持久性)
中心化和去中心化
分布式架构里面，很多的架构思想采用的是：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。
最典型的是： zookeeper / etcd
经典的CAP/BASE理论
CAP
C（一致性 Consistency）: 所有节点上的数据，时刻保持一致
可用性（Availability）：每个请求都能够收到一个响应，无论响应成功或者失败
分区容错 （Partition-tolerance）：表示系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系
CP / AP
CAP理论仅适用于原子读写的Nosql场景，不适用于数据库系统
BASE
基于CAP理论，CAP理论并不适用于数据库事务（因为更新一些错误的数据而导致数据出现紊乱，无论什么样的数据库高可用方案都是
徒劳） ，虽然XA事务可以保证数据库在分布式系统下的ACID特性，但是会带来性能方面的影响
Zookeeper
官方文档上这么解释zookeeper，它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
zookeeper能做什么
数据的发布/订阅（配置中心:disconf） 、 负载均衡（dubbo利用了zookeeper机制实现负载均衡） 、命名服务、
master选举(kafka、hadoop、hbase)、分布式队列、分布式锁
zookeeper的特性
顺序一致性
原子性：所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、
要么全都不应用
可靠性：一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的
实时性：一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态；（zookeeper仅仅保证在一定时间内，近实时）
角色
leader/follower/observer
leader
leader是zookeeper集群的核心。
1. 事务请求的唯一调度者和处理者，保证集群事务处理的顺序性
2. 集群内部各个服务器的调度者
follower
1. 处理客户端非事务请求，以及转发事务请求给leader服务器
2. 参与事务请求提议（proposal）的投票（客户端的一个事务请求，需要半数服务器投票通过以后才能通知leader commit； leader会发起一个提案，要求follower投票）
3. 参与leader选举的投票
observer
观察zookeeper集群中最新状态的变化并将这些状态同步到observer服务器上
增加observer不影响集群中事务处理能力，同时还能提升集群的非事务处理能力
observer 是一种特殊的zookeeper节点。可以帮助解决zookeeper的扩展性（如果大量客户端访问我们zookeeper集群，需要增加zookeeper集群机器数量。从而增加zookeeper集群的性能。 导致zookeeper写性能下降， zookeeper的数据变更需要半数以上服务器投票通过。造成网络消耗增加投票成本）
1.observer不参与投票。 只接收投票结果。
2.不属于zookeeper的关键部位
数据模型
zookeeper的数据模型和文件系统类似，每一个节点称为：znode,zookeeper中的最小数据单元。
节点特性
持久化节点 ： 节点创建后会一直存在zookeeper服务器上，直到主动删除
持久化有序节点 ：每个节点都会为它的一级子节点维护一个顺序
临时节点 ： 临时节点的生命周期和客户端的会话保持一致。当客户端会话失效，该节点自动清理
临时有序节点 ： 在临时节点上多了一个顺序性特性
zoo.cfg配置文件分析
tickTime=2000 zookeeper中最小的时间单位长度 （ms）
initLimit=10 follower节点启动后与leader节点完成数据同步的时间
syncLimit=5 leader节点和follower节点进行心跳检测的最大延时时间
dataDir=/tmp/zookeeper 表示zookeeper服务器存储快照文件的目录
dataLogDir 表示配置 zookeeper事务日志的存储路径，默认指定在dataDir目录下
clientPort 表示客户端和服务端建立连接的端口号： 2181
Watcher
zookeeper提供了分布式数据发布/订阅,zookeeper允许客户端向服务器注册一个watcher监听。当服务器端的节点触发指定事件的时候
会触发watcher。服务端会向客户端发送一个事件通知
watcher的通知是一次性，一旦触发一次通知后，该watcher就失效
stat信息
cZxid：这是导致创建znode更改的事务ID。
mZxid：这是最后修改znode更改的事务ID。
pZxid：这是用于添加或删除子节点的znode更改的事务ID。
ctime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode创建时间。
mtime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode最近修改时间。
dataVersion：表示对该znode的数据所做的更改次数。
cversion：这表示对此znode的子节点进行的更改次数。
aclVersion：表示对此znode的ACL进行更改的次数。
ephemeralOwner：如果znode是ephemeral类型节点，则这是znode所有者的 session ID。 如果znode不是ephemeral节点，则该字段设置为零。
dataLength：这是znode数据字段的长度。
numChildren：这表示znode的子节点的数量。
api
zkclient/curator
zookeeper的实际应用场景
订阅发布
watcher机制
统一配置管理（disconf）
分布式锁
redis
zookeeper
数据库
负载均衡
ID生成器
分布式队列
统一命名服务
master选举
分布式锁
master选举
数据发布订阅/ 配置中心
实现配置信息的集中式管理和数据的动态更新
实现配置中心有两种模式：push 、pull。
长轮训
zookeeper采用的是推拉相结合的方式。 客户端向服务器端注册自己需要关注的节点。一旦节点数据发生变化，那么服务器端就会向客户端
发送watcher事件通知。客户端收到通知后，主动到服务器端获取更新后的数据
1. 数据量比较小
2. 数据内容在运行时会发生动态变更
3. 集群中的各个机器共享配置
leader选举
1. 所有在集群中的server都会推荐自己为leader，然后把（myid、zxid、epoch）作为广播信息，广播给集群中的其他server, 然后等待其他服务器返回
2. 每个服务器都会接收来自集群中的其他服务器的投票。集群中的每个服务器在接受到投票后，开始判断投票的有效性
a) 判断逻辑时钟(Epoch) ，如果Epoch大于自己当前的Epoch，说明自己保存的Epoch是过期。更新Epoch，同时clear其他服务器发送过来的选举数据。判断是否需要更新当前自己的选举情况
b) 如果Epoch小于目前的Epoch，说明对方的epoch过期了，也就意味着对方服务器的选举轮数是过期的。这个时候，只需要讲自己的信息发送给对方
ZAB协议
拜占庭问题
paxos协议主要就是如何保证在分布式环网络环境下，各个服务器如何达成一致最终保证数据的一致性问题
ZAB协议，基于paxos协议的一个改进。
zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议
zookeeper并没有完全采用paxos算法， 而是采用zab Zookeeper atomic broadcast
zab协议的原理
1. 在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性
2. zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，
把数据的状态变更以事务请求的形式广播到其他的节点
3. zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更
4. 所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫follower
leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点
再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息
崩溃恢复
原子广播
zab协议的工作原理
1. 什么情况下zab协议会进入崩溃恢复模式
1. 当服务器启动时
2. 当leader服务器出现网络中断、崩溃或者重启的情况
3. 集群中已经不存在过半的服务器与该leader保持正常通信
2. zab协议进入崩溃恢复模式会做什么
1. 当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader。当新的leader选举出来以后，如果集群中已经有过半机器完成了leader服务器的状态同（数据同步），退出崩溃恢复，进入消息广播模式
2. 当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入数据恢复模式，找到leader进行数据同步
问题
假设一个事务在leader服务器被提交了，并且已经有过半的follower返回了ack。 在leader节点把commit消息发送给folower机器之前
leader服务器挂了怎么办
zab协议，一定需要保证已经被leader提交的事务也能够被所有follower提交
zab协议需要保证，在崩溃恢复过程中跳过哪些已经被丢弃的事务