zookeeper

议员6

跟随者

三个角色

PID=5

/

Observer观察者

客户端

发现：即要求zookeeper集群必须选择出一个leader进程，同时leader会维护一个follower可用列表。将来客户端可以这follower中的节点进行通信。同步：leader要负责将本身的数据与follower完成同步，做到多副本存储。这样也是体现了CAP中CP。follower将队列中未处理完的请求消费完成后，写入本地事物日志中。广播：leader可以接受客户端新的proposal请求，将新的proposal请求广播给所有的follower。

/zookeeper

问题活锁：所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题数据同步：各个结点数据都是不全的

E最终一致性操作后进行数据同步

Learner学习者

议员3

java0000000002

有主模式当其他节点有需求时，给总统投票，统一由总统进行询问，超过1/2节点后进行统一的发布。其他节点的请求，总统每次存储处理一个请求，速度快

python

ZooKeeper

缺点网络之间的通信，网络波动影响维护成本高，多态服务器

Leader主节点

java0000000001

领导者

Consistency:一致性：数据的最终一致

ZAB协议

候选人

临时

Availability可用性：在一定的时间内返回结果迅速

节点

BASE

临时无序唯一节点

持久

Paxos算法

Partition Tolerance：分区容错：某节点故障时，提高数据容错性

有主模式

议员2

原子广播

s:弱一致性软状态大于二分之一结点满足即可进行下一步

议员总数=6

/a

Follower跟随节点

监听原子广播监听节点的创建和销毁

Raft算法：简化Paxos算法（模型）

当数据过多时，部分议员参与投票，其他议员，只接收同步发布

议员4

CAP原则

BA：基本功能可用

无主模式

优点CAP

zookeeper

议员1

议员5

ZNode

持久无序唯一节点

线程安全