支付宝分布式事务初探

最近有被人问到分布式事务的工作原理，由于从来没做过这方面的东西，只能胡乱猜测一番，结果当然是凌乱无比。

刚好今天有支付宝的高手来分享支付宝的分布式事务。跑去听了一下，果然大有收获。在这里把今天听到的总结一下，也算是份课堂笔记吧！

分布式事务，这个东西多半都是用在金融相关的系统上，应用的场景往往是多系统跨库。

相关的业务对事务的一致性要求很高，涉及到钱的东西当然分毫不能有差。

那么怎么来处理这些系统之间的事务。保证事务的一致性，原子性，持久性，隔离性呢？

举个例子，支付宝有交易系统、账户系统、积分系统等多个子系统。

当客户发起一笔交易时，需先在交易系统中插入交易记录，然后在账户系统中进行金额的增减，最后在积分系统中给加上最新的积分。

实际的业务比这个更复杂。这三部中有任何一步失败，都需要进行回滚。那么怎么保证这三个事务会进行回滚呢？

支付宝使用的是一个二段式的分布式事务

第一阶段，通知各子系统进行业务的操作，比如可以在交易系统中对交易记录表拷贝一个副表，在副表中插入交易记录。如果执行成功，子系统返回成功的信息

在这个中间还有一个很重要的角色就是有一个总调度者，他负责控制整个事务的流程。发起事务时首先要注册到调度者上，事务完成，或者回滚也是由调度者发起！

接着上面的继续，当子系统第一阶段业务执行成功，返回成功给调度者，如果所有子系统都返回成功信息，者调度者通知子系统进行第二阶段的操作，讲数据插入主表中，如果有任何一个子系统返回失败的消息，则通知所有系统回滚。

这是一个理想的状态，前提是每次业务操作都会完成，这样事务的一致性就可以保证，但是实际情况不是这样，比如服务器宕机，网络断掉等，会导致某一阶段不能完成

这样会导致事务的不完整，所以我们还需要一个清道夫式的角色，来保证系统中事务的完整。实际上我们可以创建一个定时钟，定时去扫描所有的事务，遇到超时，或者不完整的事务，一律通知各子系统进行回滚，这样虽然有可能会导致误杀一些执行时间过长的事务，但是却保证了整个系统的事务一致，所以还是值得的。

大致原理就是如此，具体的实现方式还是有很多技巧性的东西，在这里就不深入探讨了。