“这是我参与8月更文挑战的第23天，活动详情查看：8月更文挑战”
9.奔溃恢复时选举出来的新leader如何跟其他follower进行同步数据的过程
我们还是来模拟一个场景，5台机器的zookeeper集群化部署
其中四台是follower角色用于读取数据和同步数据的，剩下的一台就是leader专门进行写操作的机器
背景：
当一个leader发出一个proposal提议后，其他三台的follower机器都收到了，唯独剩下的一个没收到proposal，但是现在已经有三台j follower机器已经返回了ack的确认字符， 所以leader判断已经都通知成功，（半数选举），然后自身开始commit，没等到给剩下的follower 角色进行提交就宕机了；
分析一下：
目前leader已经commit数据到自己的znode节点上了，但是已经挂了，但是其他四台follow机器，三台已经将proposal放到自己本地的磁盘日志文件中，剩余一台啥都没有（之前半数返回ack已经够了没有收到proposal提议），万一其他三台机器恢复机制时，都选举最后一台机器，作为新的leader,那这条数据就永久丢失了，
先告诉大家一个答案，就是这中事情不会发生，zookeeper集群不会选择一个没有数据的角色选举成leader
主要是要了解一个zxid的概念：
Zxid： 可以理解为一个事物的自增ID，要是对提议改变了，他就自增，
要是这个follow没有收到提议，也就zxid相应的比收到返回ack的follower 节点的机器肯定是大的；
选举leader的要求是，在follower中，收到事务zxid最大的，也就是相当于创建时间最早的，作为新的leader
10.zxid
-
znode节点的状态信息中包含czxid, 那么什么是zxid呢?
-
ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.
-
创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.
ZooKeeper中ZXID是一个长度64位的数字，其中低32位是按照数字递增，即每次客户端发起一个proposal，低32位的数字简单加1。高32位是leader周期的epoch编号。也就是leader的一个版本号
比如说后面epoch编号为8， 也就说当前的leader版本是8 ，挂掉之后重新选举就自增1，epoch的编号就是9
所以睡要是想之前的情况2，发生就知道是为什么会出来丢掉的数据，因为会找leader的epocn最大的一个版本作为可以提交的领导者
重新发号命令；
11.Observer节点（角色）的作用：
需要配置文件，只会单纯的接受和同步数据，observer不会参与过半写机制，不参与选举
只是被动的接受数据，
如果读的请求需求很大，我们可以添加几个Observer,
优点：
-
可一扛下很大的并发量，
-
不会影响过半写的机制，
-
不会特别影响性能
原因：
要是都是follower节点的话，当leader要发proposal提议，要等待过半的机器返回ack，然后同步数据，也是过半的，
选举的时候也是过半的，这样会很耗费时间以及网络资源，但是只要读取的数据，不参与选举的observer就很大程度上解决了这个痛点
12.zookeeper适用于实际部署场景：
适用于小集群的部署，读多写少的场景；
奇数台机器，半数选举，
过半写+磁盘日志文件====》commit+znode 节点
主要是写入压力过大leader
