【ZooKeeper】核心功能和工作机制1-ZooKeeper架构理解

zookeeper官网https://zookeeper.apache.org/
标准解释higly reliable distributed coordination
高可靠分布式协调服务
zookeeper能做什么？（What is ZooKeeper）
maintaining configuration information 配置管理
naming 命名服务
providing distributed synchronization 分布式锁
providing group services 组服务 集群管理
等

ZooKeeper架构理解

ZooKeeper是一个分布式协调服务，仲裁机构，保持一致性。多个节点如果出现了意见的不一致，需要一个中间机构调节一致。（ZooKeeper作用）

client端发给server端：一个是读，一个是写。（基本都这样）
读请求、写请求、读访问、写访问、读服务、写服务

ZooKeeper服务有多台服务器，client端连接任一台服务器都可以。client端在连接请求时，可以指定部分节点地址，也可以指定所有服务器地址。指定所有，会随机取一个，有可能连接到leader，有可能连接到follower。

follower server接收到读请求、写请求怎么处理？

follower server接收到读请求，follower节点自己直接处理。
为什么自己处理，不让leader参与处理呢？因为zookeeper系统的所有数据在leader中存储了一份，在所有follower server中也存了一份。zookeeper集群中所有数据，在所有节点都存了一份完整数据。
follower server接收到写请求，follower会转发给leader，leader server处理所有写请求。
如果client端直接连接到leader不管是读请求还是写请求，都由leader处理。

zookeeper怎么完成一次写请求？

涉及分布式执行原理相关知识，内部通过ZAB同步。
简述：leader server接收到一条写请求，leader会把它变成proposal提案，这个提案会分发（广播）给所有follower server，follower会根据自身情况执行proposal，执行完最终会给leader一个反馈ack，follower如果具备执行proporser的条件返回true，leader进行票数统计，如果超过半数同意，leader就提交这个proposal，类似于分布式事务的rpc的两阶段提交。（分布式事务两阶段提交，第一阶段让大家执行事务，但不提交；第二个阶段，征得所有服务器同意，然后再提交）
zookeeper服务内部如何完成一条数据的写入，是经过ZAB协议工作的。这个ZAB协议的工作机制是rpc工作机制。
为什么follower不支持写请求？因为分布式时钟问题，分布式环境无法界定写请求顺序。

架构细节：

1.ZooKeeper是对等架构，工作的时候，会举行选举，变成Leader+Follower架构
2.在ZooKeeper中，没有沿用Master/Slave(主备)概念，而是引入了Leader、Follower、Observer三种角色概念。通过Leader选举算法来选定一台服务器充当Leader节点，Leader机器为客户端提供读写服务，其他角色，即follower提供读服务，在提供读服务的Follower和Observer中，唯一区别就是Observer不参与Leader选举过程，没有选举权和被选举权，因此Observer的作用就是可以在不影响写性能情况下提高集群读性能
3.ZooKeeper系统还有一个角色叫Observer，Observer和Follower最大的区别就是Observer除了没有选举权和被选举权以外，其他的和Follower完全一样
4.ZooKeeper系统的Leader就相当于是一个全局唯一的分布式事务发起者，其他所有的Follower是事务参与者，拥有投票权
5.ZooKeeper集群的最佳配置：奇数个，Observer若干，Observer最好是在需要提升ZooKeeper集群服务能力时再进行扩展，而不是一开始就设置Observer角色！Follower不宜太多
6.Observer的作用是分担整个集群的读数据压力，同时又不增加分布式事务的执行力，因为分布式事务的执行操作，只会在Leader和Follower中执行。Observer只是保持跟Leader的同步，然后帮忙对外提供读数据服务，从而减轻ZooKeeper的数据读取服务能力
7.ZooKeeper中的所有数据，都在所有节点保存了一份完整的。所以只要所有节点保持状态一致的话，肯定是所有节点都可以单独对外提供读服务的。
8.ZooKeeper集群中的所有节点数据状态通过ZAB协议保持一致。ZAB有两种工作模式：
a.崩溃恢复：集群没有Leader角色，内部在执行选举
b.原子广播：集群有Leader角色，Leader主导分布式事务的执行，向所有的Follower节点，按照严格顺序广播事务
c.补充：实际上，ZAB有四种模式，分别是：ELECTION，DISCOVERY，SYNCHRONIZATION，BROADCAST
9.ZooKeeper系统中的Leader角色可以进行读，写操作，Follower角色可以进行读操作执行，但是接收到写操作，会转发给Leader去执行。ZooKeeper的所有事务操作在ZooKeeper系统内部都严格有序串行执行的
10.ZooKeeper系统虽然提供了存储系统（类文件系统：树形结构，每个节点不是文件也不是文件夹，是一个znode），但是这个存储，只是为自己实现某些功能准备的，而不是提供出来，给用户存储大量数据的，所以，切忌往ZooKeeper中存储大量数据，甚至每个znode节点的数据存储大小不能超过1M
11.ZooKeeper提供了znode节点的常规的增删改查操作，使用这些操作，可以模拟对应的业务操作，使用监听机制，可以让客户端立即感知这种变化。
12.ZooKeeper集群和其他分布式集群最大的不同，在于ZooKeeper是不能进行线性扩展的。因为像HDFS的集群服务能力是和集群节点个数成正比，但是ZooKeeper系统的节点个数到一定程度之后，节点数越多，反而性能越差
13.ZooKeeper实现了A可用性、P分区容错性、C中的写入强一致性，丧失的是C中的读取一致性。ZooKeeper并不保证读取的最新数据。如果客户端刚好链接到一个刚好没执行事务成功的节点，也就是说和Leader保持一致的Follower节点的话，是有可能读取到非最新数据的。如果要保证读取到最新数据，请使用sync回调处理。这个机制：是先让Follower和Leader一致，然后再返回结果给客户端。
14.Leader内部，有三个服务端
a.Follower和Observer提供同步服务 BIO
b.给client端提供读写服务 NIO
c.选举服务 BIO

崩溃恢复：ELECTION，DISCOVERY，SYNCHRONIZATION
原子广播：BROADCAST