从事务的原变去看代码思路

在很早之前就在想一个问题，从支付宝转账1万块钱到余额宝，我就思考支付宝扣除1万之后，如果系统挂掉怎么办，这时余额宝账户并没有增加1万，数据就会出现不一致状况了。

其实想想，很简单啊，两张表，一张加1万，一张减一万，放在一个事务里就好了。

支付宝转账余额宝为例，假设有

支付宝账户表：A（id，userId，amount）

余额宝账户表：B（id，userId，amount）

用户的userId=1；

从支付宝转账1万块钱到余额宝的动作分为两步：

1）支付宝表扣除1万：update A set amount=amount-10000 where userId=1;

2）余额宝表增加1万：update B set amount=amount+10000 where userId=1;

但是这样好像不现实吧，这样只是一个小后台程序，凑合着用就好了。可能是10年前，大家都是这么干的。数据又不大，就不会想那么远。

现在呢，2018年了，一个能赚上千亿的系统，背后的数据量应该是已经不可估量了，又要你响应快，又要你数据一致性，还要可靠性。哇，一下子问题就大条了。这些东西应该让国外的大学教授去想啊。

没错，演变就是恰巧，程序员的工作就是碰到问题解决问题。

2008年的时代，一台服务器一个数据库一个应用搞定一切系统。我的表可以无限多，我的代码可以无限嵌套。一股子写到底，你要什么功能，我就开发什么功能。

就好比要给一个勇士为他打造了一套盔甲，而这套盔甲居然是连体衣。从上面往下套就好了。如果勇士，变肥了变胖了套起来就很吃力了。

那么这时候是不是有一种东西可以替代这种方案，从人性的上面讲，大家都应该会自然而然想到盔甲解分出来，一个盔甲分成左膀右臂、上盔下衣。每个东西都是一个可组合的。（这个又是一个设计模式的原理，历史总是这么相似，无处不在的设计模式）。每个组件什么缝合在一起？

那么系统也应该如何，那如何保证每个系统互相形成一个事务呢，答案就是：分布式事务。这个东西让每个系统维护的每个库连成一片，形成一套。

好吧，不废话了，让专业说话，通过下面这个传送门，连成一片：

https://www.jianshu.com/p/9845da31eb92