zookeeper学习笔记-个人备注-后续待补

  zookeeper

本文仅用于个人回忆

 属于 cap种的 CP,

eureka：属于AP
    注册中心、负载均衡、配置管理、分布式锁、自增唯一序列值
    1、节点唯一 2、事务性操作全属于leader顺序执行 3、一个SESSION 对应临时节点，回话结束，临时节点消失
    4、节点是有序的 5、watch触发机制，即节点的变动，会触发客户端的回调程序。
    举个例子：自增唯一序列值，
         每个客户端实例，调用zk生产有序节点，默认32位的值，每隔节点名称唯一，而且执行是leader顺序执行，即可达到目的
    leader、fellower、obsercer
    leader选举机制/数据同步机制，二段提交机制：1、请求提交 2、请求执行，

     多数大于少数，过半机制，过半fellower返回ACK给leader，即可confirm

    修改版的2PC机制。
    fellower:处理非事务性请求，把那个转发事务性请求给leader，参与投票

   observer： 新增节点可提升性能，但也会多了投票，影响性能，因此不参与投票

  节点数：2N+1 奇数节点

增加节点，提高读请求效率。同步、投票的效率降低。出现了observer角色，只有同步

没返回ack的fellower，会最终同步，最终一致性。

----------------------------------------------

ZAB协议：支持崩溃恢复、原子广播的协议
    各个节点 数据一致性

1、原子广播：新leader选举后，同各节点同步数据

每一个消息，都会有一个自增zxid（可认为是版本号），leader会分发zxid信息到fellower节点，fellower收到后，写入磁盘，并返回ACK,leader收到合法数量的ACK时，会进行confirm

2、崩溃恢复

     前提： leader挂了 或者 leader失去过半fellower节点

     例如：fellower1收到，并commit，leader挂了，fellower2就没收到confirm信息,

ZAB协议 要保证已处理的信息不能丢失。已丢弃的消息要丢弃（leader收到信息,还未prepare，挂了）。

每产生一个leader，leader的epoch会加1，类似于改朝换代。zxid是64位，低32位是自增器，高32位是epoch编号，保证老的leader起来以后，不会成为leader,因为zxid小。

       

 ------------------------------------------------

设计猜想：

       1、防止单点故障，高可用：集群 。

       2、事务请求：leader机制 、用于数据同步

       3、leader挂了呢，ZAB协议

       4、leader如何保证强一致性：2PC协议