[RocketMQ - 5] 关于 Rocketmq 事务消息和两阶段提交的理解

关于 Rocketmq 事务消息和两阶段提交的理解

本文主要是对事务、事务消息、两阶段提交中概念的理解和解读，因此不会过多地解释具体地运行逻辑。如果想要了解，可以参考前人的文章

1. 事务及两阶段提交

1.1 事务的 HelloWorld 级理解

许多文档或文章中都会使用那个张三给李四转钱的例子来解释事务及其存在的必要。(即A账户-100，B账户+100这两件事，应该同时成功或失败，不能一半成功一半失败)

而要解决这个问题就引入了两阶段提交，第一阶段向 A 和 B 发送 prepare，让 A 和 B 准备好扣钱和加钱，即冻结这部分钱，然后当 A 和 B 都检查完毕没有问题并返回准备完成后，执行第二阶段，发送 commit 让 A 和 B 执行操作。

这看起来通俗易懂，但似乎很容易地就发现了，这么做似乎还是会出现一个成功一个失败的问题啊。没错，确实如此，比如 commit 万一其中一个没收到，所以还有很多工作要做。

但你需要知道的是，实际上，到此为止两阶段提交已经"结束"了。接下来的问题其实已经不是两阶段提交需要解决的了。也就是 “两阶段提交能处理业务异常的失败，处理不了系统异常的失败”

因此，接下来我们也不会探讨如何解决这些问题，但我们还是需要知道有哪些问题需要解决以及由谁解决。也就是我们需要什么样的系统才能满足两阶段提交。

1.2 两阶段提交的系统稳定性探索

很显然到目前为止，两阶段提交已经为我们解决了很多的问题，比如 A 账户余额不足，B 账户不存在等，这些业务逻辑上的错误我们已经能够避免了。但系统的网络并不总是通畅的，系统也不是永远能稳定运行的。比如网络波动，比如宕机都会影响到执行的结果。遗憾的是，两阶段提交并不能解决这些问题。

“好在”我们需要的“仅仅”是保证最终一致，那么如果发送 commit 失败，我就能够通过不断重试最终让 commit 成功，或者是所有机器都宕机了，那这些机器就要保证在重启后能够互相协商，并且准备阶段需要把状态落盘进行持久化等等，甚至你还要考虑要是连硬盘都坏了呢。

这可以考虑到很深很深，但意外总会发生，我们只能尽可能减小他发生错误的概率，不过这些都不是两阶段提交的内容了。而我们在实现事务消息的时候也只需要根据实际情况做出相对合理的应对就行了，比如对于普通的业务我只需要保证只要硬盘不出问题我的系统就是稳定的，就足够了。

(这里还暂时不引入协调者这个概念，因为协调者和客户端的行为十分相似，即使不引入，也能够支撑讨论，引入后反而增加理解难度)

1.3 关于超时的讨论