zookeeper server 是如何启动的
我们使用 zkServer.sh start 进行启动 zk 服务器，查看这个脚本的代码发现实际上调用的是 QuorumPeerMain 的 main 方法
我们讲解 zk 集群模式的工作原理，先看下图是 server 启动弄的整体架构组件工作原理图，然后我大概解释一下各大核心组件
启动时候运行的核心组件
上图我们可以看到三种颜色的组件图
- 黄色：监听了 2181 端口，大概应该知道这个端口就是负责与客户端通信的，围绕这一块的核心组件是
NioServerCnxnFactory - 蓝色：监听了 3888 端口，这一系列组件主要是用于集群选举用的，选举成为 leader 还是 follower 还是 observer，围绕这一块的核心组件为负责通信的
QuirumCnxManager，负责选举的FastLeaderElection - 紫色：监听了 2888 端口，这一系列组件主要是用于选举完成后确认好了各个 server 所处的角色之后，leader 和 follower 需要进行数据交互，围绕这一块的核心组件为 Leader（Follower） 组件
同时我们可以看到这一系列的组件都是包含在 QuorumPeer 这个中心组件之中，可以说这就代表了一个 zk server，可以想象成各大组件就是一个人的各个器官，从而组成了 QuorumPeer 这个完整的人
在上图完整的画出了 Leader 的核心组件，Follower 的这些组件跟 Leader 是一样的，不同的是 Follower 在选举完成后创建的不是 Leader 组件而是创建的 Follower 组件
ZKDatabase 代表了一个内存数据库，写入到 zk 的数据会被全部记录在内存中，同时重启之后也会将磁盘的数据恢复到内存中
整体流程梳理
启动 zk server 创建一个 NioServerCnxnFactory 用于跟客户端进行网络通信
创建一个 ZKDatabase 通过使用 FileTxnSnapLog 加载磁盘快照文件 + proposal 日志文件恢复出来一个内存数据库
创建一个 QuirumCnxManager 负责集群之间的投票信息传递，各个节点会发送给对方当前机器的 zxid、epoch、myid 值给对方
创建一个 FastLeaderElection 读取归档各个节点的投票数据，最终决策出来谁做 Leader、Follower、Observer
最后根据当前节点所属角色创建 Leader、Follower、Observer，他们会另外绑定一个端口用于集群之间的数据同步，针对每个连接创建一个线程处理，同时为了避免连接重复绑定创建，只允许 server id 大的向 server id 小的发起连接，小的发往大的会比强制关闭
思考
从 zk 服务器的启动我们可以看到，对于网络调用的处理，什么情况下适合用 BIO，什么情况适合用 NIO，以及不同的端口各成体系，逻辑独立，易于拓展、维护、同时容错性也更高
与客户端通信的时候，可能存在大量客户端的连接和高并发的读请求默认最大连接客户端数量为 60 个可以调整大小，如果采用 BIO 的话需要为每个客户端创建一个线程，就算客户端没有请求也会占用线程资源
集群之间的通信采用的是 BIO，为每个客户端之间的连接创建一个线程来处理，因为集群结点相对较少
集群之间的通信选举使用 3888 端口，leader 和 follower 信息同步采用 2888 端口，二者互相隔离就算某一方有错误也不会影响到对方
本文转载自: 掘金