啥？分布式啥？啥事务？

最新推荐文章于 2024-04-26 13:35:49 发布

Hollis Chuang

最新推荐文章于 2024-04-26 13:35:49 发布

阅读量323

点赞数

文章标签：分布式网络数据库 java zookeeper

二将军问题

我们先来看个故事，相信会有助于你对分布式事务的理解。二将军问题是一个计算机领域一个经典的问题。

「故事背景」黑白两军交战之际，两股白军将黑军被围困在山谷之中；山谷两侧任意一股白军都比山谷中的黑军人数少，因此单独一只白军向黑军发起进攻，必败无疑，但是两股白军人数总和却比黑军人数多，若能同时向黑军发起进攻，则可大胜。而山谷左右侧的白军相互通信（告知进攻时间）必然会穿过山谷，但是有被黑军俘虏的风险，如果你是山谷左侧的白军统帅，你会如何抉择呢？

「战况分析」

「情形1」:送信失败，如下图所示，左侧白军穿过山谷的时候被黑军俘虏了，右侧白军仍旧不知道左侧白军的进攻信息。

送信失败

「情形2」:送信成功，回信失败。如下图所示，左侧白军穿过山谷将信息成功通知给右侧白军，但是右侧白军携带"收到命令"的信息，穿过山谷向左侧白军通知的时候被黑军俘虏了，此时左侧白军不知道右侧白军是否接收到进攻命令。

送信成功，回信失败

「情形3」:送信成功，回信成功，如下图所示，白军胜利毫无疑问。

送信成功，回信成功

「战役复盘」

面对不稳定的信息传输通道(山谷中的黑军)，要完成两股白军的通信是有难度的，送信回信的过程就好比我们系统中Send和Ack 的过程，并且只要送信或者回信任意一次失败，整个信息传递就标志着失败，无法完成进攻，这像不像CAP的最佳打开方式中提到的原子性，事务中的每个操作都成功，事务才会提交。
如果真的发生了情形1和情形2，如果你是左侧白军的统帅或者右侧白军的负责人，你该怎么办呢？是不是应该等等，看看有没有回信，如果长时间没有回信就认为这个送信的人被俘虏了，再派1个人重复送信的过程，这就是我们在系统中常见的超时重试。当然重试一定是有限制的，如果真的无限重试。那么左右侧白军人数有可能会清零(资源耗尽)，战争自然失败(系统自然崩溃)
如果左侧白军派遣多名士兵同时发起送信的动作，那么对于右侧白军来说不管收到多少次信息，都只进攻一次。类比咱们系统来说，对于不管是一次请求还是多次请求，结果都是一样的，这就是系统幂等性
这个二军问题，像不像TCP链接的握手的过程呢？问题来了，为什么是三次握手，而不是两次握手?文章留言回复下，如果你不知道可要补课啦

本地事务

本地事务实际上是指传统的事务，也就是大学课程里数据库原理中的提到事务。在CAP的最佳打开方式的文章中，我们也可以看到，ACID就是本地事务的最好诠释，原子性、一致性、隔离性、持久性，详细解释不再赘述，可以参看CAP篇中的含义。

当时我是用的午休去超市买苹果来举例，我们再简单重温下本地事务。当我在超市选好苹果去结账的时候，超市系统突然崩了无法结账，虽然选好了苹果，但也没啥用，虽然这次买苹果的事务自然而然也就失败了。但是对于超市来说，所有数据都不曾有任何变化，这就是本地事务。

分布式事务

我们沿着本地事务的思路继续深入，这次超市系统崩了的原因是超市发展很快，数据量的不断增长，导致后端单数据库性能已经达到了瓶颈，于是开始进行分库(分到多个物理实例)原来在单库中会操作多个表，由于不涉及网络传输，直接通过RDBMS的undo log、redo log以及锁机制就可以满足本地事务的所有需求了，但是分库后，意味着出现了跨库、跨网络的的事务场景。

举个例子，在分库前，优惠券逻辑使用的表A和支付逻辑相关的表B在同一个库中的，此时超市有苹果促销的活动，使用优惠券和支付逻辑是在同一个事务中，因此在操作支付时，如果支付失败，本地事务会强制将使用优惠券的操作也会失败。而由于分库拆分成两个独立实例，也就导致在跨网络的情况下，无法将单机事务在数据资源层面完美支持，因此介于此种情况，自然而然有了分布式事务的应用场景。

我们来明确下什么是分布式事务，通常分布式事务中存在两种角色

资源管理器（Resource Manager, RM）即事务参与者
事务管理器（Transaction Manager, TM）即事务协调者

在分布式事务的模型中，RM对应着资源，一个DB、一个被依赖服务都是一个RM；而TM 是一个全局事务管理器，一个TM会管理多个RM，就类似上面我们的超市促销支付的逻辑去协调多方数据库资源，从而协调各个本地事务的进度，使其共同提交或回滚，最终达成一种全局的 ACID 特性。

两种事务的区别

实际上与分布式系统CAP类似，分布式事务中涉及到的所有参与者会分布在同一个网络环境中，参与者会通过相互通信达到分布式系统的一致性，但因为网络环境的不确定性，网络不可避免的会出现超时、失败的情况，进而可能导致数据出现不一致的情况。而本地事务并不需要多次rpc，自然也就也就不存在分布式一致性问题，分布式一致性的核心点在于数据的分布式操作，导致本地事务无法保证数据的原子性。

举个实际的????，我们工作中经常会有独立负责一个项目的情况，自己会了解项目的所有逻辑，不需要和其他人交互。此时如果项目参与的人数增加到多个，成立了一个项目组，要想顺利的继续完成项目，就会导致你经常需要和项目组的其他人进行交流，保持目标/进度的一致，此时这个项目组就是分布式系统，每一个项目组成员就是分布式系统中的节点。由于沟通的不确定性，当某个模块废弃时，除了自己本地修改外，还需要通知所有人修改。这时如果沟通的不到位，就会出现不一致的情况。因此在分布式事务中会出现一个全局协调者的角色(TM)，协调所有资源(RM)步调，保证全局一致。