淘宝取代分布式事务的方案

下面，我们针对上面的这个流程的一些抉择的点进行一些探讨。

首先，是bob这个机器，这里涉及第一个抉择点。

如果bob(消费者)是个消费大户，短时间内进行了大量购买，那么可能会造成的问题是，bob所在的那个

机器会成为热点，如果在某个突发的情况下，某个账户突然成为热点，那么这些有状态的数据很难快速

的反应并加以处理，会造成事务数在某个单节点大量堆积。造成挂掉。

可能的解决方法是：

1.利用两段提交协议来让原来的” 将需要给smith加100块这个操作，以事务的形式插入到同机(A)的一张

log表中，并自动生成一个唯一的transactionID”这步操作放在另外的一台机器上进行。

这样做的的好处是，无论bob怎么是热点，都可以通过水平的加log机器的方式来防止这种热点的产生。

坏处则有：

1方案复杂度高

2额外的网络开销

3消息基于网络发送后，会可能得到三个可能的反馈：1. 成功 2. 失败 3. 无反馈。最麻烦的就是这个无

反馈，他可能成功，也可能失败。所以是不确定的状态，需要进行事务的两边进行第二次确认，来确保这个

事务的参与方是否都做了该做的事情，如果有一方做了类似commit的操作，那么另外的一方应该commit.如

果两方都没做commit操作，那么应该回滚。

2.让bob的库余量更高，并按照访问压力进行数据的切分，按照热度进行数据划分，放弃原有的简单取mod

的策略。来兼容这种不均匀特性。

其次，如果有80个系统都关注着smith加了100这个操作的log，要做对应的处理（比如一些人要针对这个加

钱操作做个打款短信推送，有些要做个数据分析等等），那么这里就有另外一个问题，这些系统对bob所在

的库的读取就会让该机器成为悲剧的存在。

所以，可以考虑的方式是，增加一个队列，使用，推，拉，或推拉结合的方式将smith加100这个操作加以分

发。这样就可以减轻主机的压力。

坏处则是：

1方案进一步复杂

2如何保证log到数据分发服务器之间的数据同步是安全的和准确的？

3如何保证分发服务器的可靠和冗余？

4如何保证写入分发服务器的数据的安全和可靠？

再次，smith这边也有问题，为什么要使用一张去重表呢？其实是因为，在发送端，也就是队列将数据发送到

目标机器后，也可能从目标机获取到三种不同的反馈，一类是成功（这个占了大多数）。一类是失败。还有一

类是。。。没反馈。

当然，最麻烦的还是这个没反馈的情况，没人知道这时候到底对方是做成功了呢？还是没做成功，为了保证最

大的吞吐量，又不能其他人都不做事儿了，就等对方的反馈。所以这里就有另外的权衡了。

一般的模型有两类，一类是用分布式事务来完成。

一类是使用努力送达的模型，说叫努力送达，顾名思义，就是只有得到成功的反馈，才停止投递，而其他时候

则重复投递消息，直到对方反馈成功为止。

两种模型比较，显然应该追求速度而放弃方便性，于是我们主要来说说这个努力送达以后所带来的影响。

影响一: 会有重复的投递，也就是说，这个消息可能会投多次，这对于update set version=version+1 这类的操作来说，是个比较毁灭性的打击。

影响二：如果需要重复投递的消息过多，会导致log分发的机器消耗大量资源来进行重复投递。这会影响server的稳定性。

影响三：如果大量堆积消息，那么会造成消息的严重delay。smith发现自己在1个月后收到了bob的钱，你说他会不会去K咱一顿。

最后，额外记的这两次log其实在某些场景下也是可以省去的。

以上，就是我在尝试还原淘宝的消息和事务系统时所能大概想到的一些非常需要权衡和注意的问题点。