无法启动分布式事务_分布式-Zookeeper

作为一名 java 开发人员，离不开各种各样的中间件，这其中又以 zookeeper 最常见。zookeeper 还有一个特点，它是 java 实现的。非常适合 java 开发人员 学习，提升自己。

学习源码是提升自身能力很重要的一步，源码不能一开始就学习，很容易从入门到放弃。

需要对这门技术很有相当的了解，才可以开始。我这里列举了一些

ZooKeeper 到底是什么，它能做什么？

直译：从名字上直译就是动物管理员，动物指的是 Hadoop 一类的分布式软件，管理员三个字体现了 ZooKeeper 的特点：维护、协调、管理、监控。

简述：有些软件你想做成集群或者分布式，你可以用 ZooKeeper 帮你来辅助实现。

特点：

• 最终一致性：客户端看到的数据最终是一致的。
• 可靠性：服务器保存了消息，那么它就一直都存在。
• 实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据。
• 独立性（等待无关）：不同客户端直接互不影响。
• 原子性：更新要不成功要不失败，没有第三个状态。

注意：回答面试题，切忌只是简单一句话回答，可以将你对概念的理解，特点等多个方面描述一下，哪怕你自己认为不完全切中题意的也可以说说，面试官不喜欢会打断你的，你的目的是让面试官认为你是好沟通的。当然了，如果不会可别装作会，说太多不专业的想法。

ZAB 协议

ZAB 协议是 ZooKeeper 自己定义的协议，全名 ZooKeeper 原子广播协议。

ZAB 协议有两种模式：Leader 节点崩溃了如何恢复和消息如何广播到所有节点。

整个 ZooKeeper 集群没有 Leader 节点的时候，属于崩溃的情况。比如集群启动刚刚启动，这时节点们互相不认识。比如运作 Leader 节点宕机了，又或者网络问题，其他节点 Ping 不通 Leader 节点了。这时就需要 ZAB 中的节点崩溃协议，所有节点进入选举模式，选举出新的 Leader。整个选举过程就是通过广播来实现的。选举成功后，一切都需要以 Leader 的数据为准，那么就需要进行数据同步了。

Zookeeper 的数据节点 Znode

• 持久节点：和我们存储到数据库的情况一样，存上了就不会丢失。
• 临时节点：你通过 ZK 客户端远程连接到 ZK 服务端，创建了临时节点，等待你的连接超时了，对不起这个节点就删除了，这就是临时节点。
• 持久顺序节点：首先它是持久化的，然后如果你创建了同名的节点，它不会说节点也存在，而且在名字后加上后缀。就像 Windows 的创建文件夹一样，后缀是数字从小到大，所以也就有了顺序性。
• 临时顺序节点：临时节点和顺序节点上面都解释过了，没错，就是它俩的组合，客户端连接超时节点就会消失，同名的节点后缀是排序的。

Zookeeper 底层用的 TCP，TCP 是可靠连接，为什么会有网络信息丢失的问题？

TCP 协议只能保证 TCP 层的可靠，所以数据到了应用层就不受控制了，而且我们需要的是应用层的可靠性。

看下图一目了然：

看到上图，这是在一台机器内部，可能传输出问题的概率不高，还有第二个原因：

TCP 协议只能保证同一个 TCP 连接内的消息是有序的。但在分布式系统中，发送数据，可能多个 TCP 连接发送一起发生一段数据，这个不同 TCP 连接的数据顺序 TCP 协议不会保证的，应用层协议也不保证，只能我们代码实现时控制。

看图 2：

分布式事务的两阶段提交协议 2PC

第一阶段：

• 协调者问所有参与者你那里是否能够提交数据，不管能不能都告诉我结果；
• 参与者收到数据就开始执行，将 Undo 和 Redo 信息写入日志，执行但是没有真正提交，等下一步操作再做最终处理，现在的情况是可进可退。
• 每个参与者都把结果如实告诉协调者。

第二阶段：当协调者从所有参与者获得的相应消息都为同意时：

• 协调者向所有参与者发出开干的命令；
• 参与者完成最终的数据操作；
• 参与者告诉协调者节点一定都搞定了；
• 协调者得到所有参与者节点的好消息，这才算是完成事务。

如果执行失败呢，也是一样的回滚流程。

两阶段提交看似不错，但是有个阻塞的问题，这个问题 两阶段无法解决，需要三阶段来解决。

分布式事务的三阶段提交协议 3PC

三阶段提交针对两阶段提交有两个改动点：

• 引入超时。如果等待时间过长那就超过了，不会一直等下去，解决了如果出现阻塞的麻烦。
• 多了一个准备阶段。一些可能出现的地方放到准备阶段了，这也是名字的由来。

第一阶段

2PC 的准备阶段很像。协调者向参与者发送处理数据的请求，参与者如果如果做好了就给好消息，搞砸了就给坏消息。

第二阶段

协调者根据参与者的好消息们来判断是否可以继续事务的 预提交操作。

如果都是好消息，那么就会执行事务的预执行。

• 发送请求：向参与者发送预提交请求。
• 预提交：参与者接收到预提交请求后，会执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中。
• 反馈：如果参与者成功的执行了事务操作，继续返回好消息，然后等待最终指令。

万一有谁向协调者报告了坏消息，或者超时了，协调者都没有接到参与者的消息，那么就执行事务的中断。

• 发送请求：协调者通知所有参与者中断事务。
• 中断事务：参与者收到中断请求之后，中断事务。

第三阶段最终的事务提交：

执行提交

• 协调者发送请求：协调通知所有参与者真正的提交事务请求。
• 参与者事务提交：参与者接收到真正提交事务的请求之后，执行正式的事务提交。
• 参与者反馈：事务提交后，告诉协调者好消息。
• 协调者完成事务：协调者接收到所有参与者的好消息之后，完成事务。

中断事务

规定时间内，协调者收到的好消息数量不够，那么就会执行中断事务。

• 协调者发送中断请求：协调者向所有参与者发送中断事务请求。
• 参与者事务回滚：参与者接收到中断事务请求之后，利用其在阶段二记录的 Undo 信息来执行事务的回滚操作。
• 参与者反馈：事务回滚之后，向协调者发送 回滚完了。
• 协调者中断事务：协调者接收到参与者反馈的回滚完成的消息之后，执行事务的中断。

三阶段提交的问题：

网络分区可能会带来问题。但是很少会有人再提四阶段了，事实上大家一般用 TCC 的思想来解决分布式事务的问题。

这几个话题，可以让人对 Zookeeper 有个大体的了解，而 Zookeeper 的源码难点也就在选举，zab 这些实现上。Zookeeper 我学了很久，具体的使用，到内部的原理，最后到代码的实现，真的很适合 java 开发者 用来晋级。