目录

1.CAP原则 

2.Paxos算法 

2.1无主模式

2.2有主模式

3.Raft算法

4.ZAB协议（Zookeeoer源子广播）

    4.1简介

4.2原理

4.3协议内容

1.CAP原则
 

定义
        C：一致性
            更新操作完成后并且返回客户端，所有的节点数据保持一致
        A：可用性
            服务一直可用，而且是正常的访问
        P：分区容错性
            应用虽然是分布式系统，当一个或则几个节点出现错误剩下的还可以满足一致性和可用性
    取舍策略
        只能满足定义中的2个

2.Paxos算法
 

2.1无主模式

每一个议员都有自己的想法

2.2有主模式

• 只有一个主发送指令
•         当主存在故障的时候重新选主
•             确保数字编号（议员的ID），为了重新选主
•             确保事务编号，有点议员数字没有更新，则不参数选主，保持数据的一直性
•         如果存在多个主就会产生脑裂问题
•             遵循过半原则
•             只有超过半数的议员同意才可以成为新的主

3.Raft算法

适用于一个管理日志一致性的协议
    将一致性算法分为了几个部分，包括领导选取（leader selection）、日志复制（log replication）、安全（safety）
    Raft将service划分为3种状态
        leader（领导者）
        Follower（跟随者）
        Candidate（存在选leader阶段，想变成leader先成为Candidate）

4.ZAB协议（Zookeeoer源子广播）

   
4.1简介

Zab协议借鉴了Paxos算法
Zookeeper是通过Zab协议来保证数据的一致性

4.2原理

发现
            zookeeper集群必须有一个leader进程，leader会维护所有的follower可用的列表
 同步
            leader将自身的数据与所有的follower的数据完成同步，体现了CAP原则中CP
传播
            leader接收客户的新的请求，进而广播到所有的follower

4.3协议内容

崩溃恢复之数据恢复
            当leader出现网络中断就会重新选leader，当主选择出来后，并且集群中有超过半数的机器跟leader完成数据的 同步就会退出ZAB协议
            这时如果有一台新的机器加入集群就会从leader同步数据
            在消息广播事务中中，leader每次会将事务分配唯一的标识，Zab协议将原则按照严格的先后顺序进行广播
        消息广播之原子广播
            在zookeeper集群中，等待所有的议员反馈ACK确认消息后，在发送commit
            在Zab协议中，leader进行广播只需要follower超过半数的ACK反馈就可以了，不需要收到全部