【Zookeeper系列】写请求在Leader内事务处理流程
在开始阅读之前，咱们先思考一个问题，Zookeeper是强一致性的吗？还是最终一致性？
先直接给答案哈，Zookeeper是保证顺序最终一致性！但为什么不是强一致性的呢？接下来，带着疑问往下看~
前置知识
在了解Zookeeper保证最终一致性之前，先看下涉及到的关键内容。比如ZK内为了保证事务消息，运用到2PC的思想，实际处理写请求的过程中，会经过Proposal流程和Commit流程
2PC（Two-Phase Commit）
2PC即二阶段提交，与二阶段提交相似的，还有三阶段提交。二阶段提交和三阶段提交可以认为是一种一致性协议，保障在分布式系统中数据的一致性，主要用于分布式事务的场景中。
二阶段提交，顾名思义就是分为两个阶段提交请求嘛，其流程可以认为是准备阶段和提交阶段
以下是简单的概括，其流程和原理实际上挺复杂的，但为了不跑偏文章的主题，就简单的概括一下2PC是什么。
-
准备阶段：事务的发起者本地执行事务，但不提交事务；然后给各个相关的服务发起分布式事务的提交请求，然后等待其他服务的响应；至于其他接收到提交请求非服务器，会给事务发起者响应ACK，可以简单认为是是否可以执行
-
提交阶段：当事务发起者收到所有的响应，如果所有的响应都是YES（可以执行），就提交本地事务并让其他服务执行事务请求；如果有部分响应不是YES，则回滚本地请求
Zookeeper处理事务流程
-
Proposal阶段：Leader会将写请求封装为一个Proposal提案，每个Proposal提案有一个全局Id，即zxid；然后会发送到所有的Follower，当Follower接收到后，会给Leader响应ACK
-
Commit阶段：当Leader接收到超过一半的Follower响应的ACK，就会认为Proposal发送成功，执行本地事务，并发送Commit消息给所有Follower；当Follower接收到Commit消息后，会将Follower内本地消息提交。
写请求事务处理
经过上面的前置知识了解，Zookeeper处理消息的事务流程，主要是Proposal和Commit阶段。
接下来，以文字结合图片的形式，大致了解写请求的过程。
-
客户端发送写请求，Leader接收到写请求后，生成Proposal提案且生成全局的zxid，并将Proposal提案写入磁盘事务日志文件。但实际上，为了提高性能，会先将Proposal写入os cache中，再在某时机将os cache中的内容写入磁盘事务文件
【1】写请求发送到Leader的过程.png
-
写入Proposal提案后，Leader会广播到每个Follower都独有的FIFO队列，这样的话，就能保证数据的顺序执行；当Follower接收到Proposal后，同样会类似Leader那样为了提高写数据的性能，先写到Follower的os cache中，然后在某时机写入磁盘事务日志文件；当Follower写入Proposal后，会给Leader响应ACK
【2】写请求发送到Leader的过程.png
-
当Leader接收到的ACK超过集群的一半，就会认为Proposal提交成功。Leader本地就会执行事务，将数据封装为Znode写到内存中，并发送commit命令给所有Follower，当其它Follower接收到commit命令后，同样会将数据封装为Znode写到内存中。
【3】写请求发送到Leader的过程.png
目前为止，就可以认为写请求处理完毕，客户端可以从Leader读取刚刚的写请求，但如果客户端从Follower读取的话，一定能读取到吗？
这就要回到文章开始的一个思考题，其答案是Zookeeper不能保证强一致性，只能保证顺序的最终一致性。咱们回过头想下写请求的事务处理过程。
当写请求生成的Proposal被广播到每一个Follower，只是先写到os cache或磁盘事务日志文件中，这时候并没有生成Znode写到内存，对于客户端来说是读取不到的；如果Leader发出commit请求的时候，由于网络原因或者Follower短暂的失去与Leader的连接，其实都有可能出现短暂的消息不一致，这是如果客户端请求访问还没生成Znode数据的话，肯定读取不到。所以这就解释了，为什么Zookeeper并不能保证强一致性。
但为什么说Zookeeper能保证顺序最终一致性呢？
这是因为Leader与Follower提交Proposal都是经过FIFO的队列，其保证了数据有序。除此之外，如果Leader提交commit后，Follower没有及时接收到commit，会有其他保障机制，保证最后集群内所有服务器都趋于数据一致。
以上就是写请求落在Leader上的大致经过，如果写请求落在Follower是怎样呢？其实流程上是没什么区别的，只不过是Follower将写请求转发给Leader，由Leader去处理写请求，然后就和上诉的流程一样，最后达到数据最终一致。
如果觉得文章不错的话，麻烦点个赞哈，你的鼓励就是我的动力！对于文章有哪里不清楚或者有误的地方，欢迎在评论区留言~
