zookeeper的广播模式和恢复模式

zookeeper是什么

zookeeper是一个高性能分布式应用协调服务。zookeeper主要可以提供如下的服务：（1）Naming Service；（2）配置管理；（3）Leader Election；（4）服务发现；（5）同步；（6）Group Service；（7）Barrier；（8）分布式队列；（9）两阶段提交

zookeeper的广播模式

1、先来了解几个小知识点

   1）Client与Server是通过NIO方式通信的。

   2）消息是FIFO方式执行的（顺序的，先进先出）。

   3）读消息可以通过zookeeper的leader和所有的follower。

   4）写消息必须通过leader。

2、zookeeper写消息的过程

   （1）Client通过某个follower请求写操作时，该follower会把这个请求发给leader；（2）leader再将这个更新（proposal），顺序发送给follower；（3）follower收到leader更新时，follower会将数据持久化到磁盘；（4）当follower写到磁盘后，就会向leader发送ACK；（5）当leader收到半数以上的follower向它发送ACK后，就向全部的follower发送commit；（6）leader并在本地commit消息（commit的意思是就是这个消息可对外读了）；（7）当follower收到leader发送的commit后，就会将磁盘里的数据写进内存数据库，同时commit（每个follower都有内存数据库，Client去向follower请求数据时，都是通过内存数据库读取的）。同时每条消息，都有一个递增的id。

zookeeper的恢复模式

1、进入恢复模式

    当leader宕机或者丢失大多数follower后，即进入恢复模式。

2、结束恢复模式

    新leader被选举起来后，且大多数的follower完成与leader的状态同步后，恢复模式即结束，进入广播模式。

3、恢复模式的意义

每个消息的id（zxid）是64位，前面32位称为epoch，后面32位称为counter。

（1）发现集群中被commit的proposal的最大的zxid，之后的leader不会commit比这zxid小的proposal，也就是说leader只能commit比这大的proposal。

（2）建立新的epoch，从而保证之前的leader不能再commit新的proposal（每选举出一个新的leader，epoch都会改变，且比之前的大，且保证一个leader的任期内，epoch不会被改变）。

（3）集群中大部分节点都commit过前一个leader commit过的消息，而新的leader是被大部分节点锁支持的（会选举出于前leader保持最为紧密的follower作为leader），所以被之前leader commit过的proposal不会丢失，至少被一个节点所保存。

（4）新的leader会与所有follower通信，从而保证大部分节点都拥有最新的数据。

zookeeper的注意事项

（1）顺序一致性：从一个客户端发出的更新操作会按顺序发送被执行。

（2）原子性：更新操作要么成功，要么失败，无中间状态。

（3）一个客户端只会看到一个view，无论他连接哪台服务器。

（4）zookeeper的读性能好与写性能（只有leader能提供些服务，任何server都可以提供读服务）。

（5）为了保证leader选举顺利进行，通常将server设置为基数。

（6）kafka主要使用到zookeeper的配置管理 和 leader Election。

（7）只保证同一个客户端的单一系统镜像，并不保证多个客户端在同一时刻一定能看到同一系统镜像，如果要实现这种效果，需要在读取数据之前调用sync操作。