zk

zookeeper是一个数据库

zookeeper是一个拥有文件系统特点的数据库

zookeeper是一个解决了数据一致性问题的分布式数据库

zookeeper是一个具有发布和订阅功能的分布式数据库（watch）

 

 

cap

 

Consistency:一致性（强一致性）

Availability:可用性

Partition Tolerance:分区容错性

 

 

领导说 “今天下午3-4点，大会议室是开会，做未来规划。收到请回复”。

看到通知的同事回复 1

领导会看有多少人回复了他这条通知，如果回复的人太少，他可能再次通知；如

 

果回复的人比较多，他就放心了，他并不会统计是不是所有人都回复了。

等到下午3点，所有同事一起开会，做未来规划。

 

zab协议

 

领导-过半机制

预提交，收到ack,提交（2pc，两阶段提交）

数据同步（节点重启的时候）

 

日常生活的场景

1、投票

2、选票

3、投票箱

4、选取结果（过半机制）

 

 

比如选班长过程

 

1、投给自己（可能）

2、沟通，改票，pk

 

 

 

 

 

 

pk

1、数据最新

事务性请求：create,set,delete

事务日志：

 事务id:zxid（数据越新，zxid越大）

 

zxid更新，要求大多数都更新（包含自己，过半），才有效。

 

非事务请求：get exist

  1. myid越大，胜出越大

 

  1. 新加入不会需要重新选举。

如果zkid大，他会回滚，之后保存与leader相同的zkid。

 

领导者选举的结点

集群启动

leader挂掉

follower挂掉后leader发现

已经没有过半flollower跟随自己了，就不能对我外提供服务了（选举者选举）。

 

 

 

节点分类

选举参与者 leader和follower

非参与者 observer

 

learner ：follower、observer

 

内存结构 DataTree

物理文件 事务日志

 

接收一半的ack进行提交，更新DataTree

 

 

服务启动总结

  1. 投自己
  2. 接收其他服务器的选票
  3. pk, zxid 和myid
  4. 我当前投给了谁：最厉害的那台服务器
  5. 投票箱
  6. 统计：超过一半的人和我投同样的服务器。

 

 

zk使用过半机制，避免了脑裂。活动参与者大于总参与者的/2.(而不含等于）。

这就解释为什么使用奇数的原因。

比如5个节点，最多挂掉2节点点才可用。6个节点，也是最多挂掉2个节点。

但是这里参与者是leader和follower，但是我们可以增加observer节点，可以增加读性能，observer不参与选举的。

observer没有两阶段提交的过程，而是直接通过leader到observer（一步到位）