阿里分布式事务设计思路

数据库不在一个实例上面，比如支付宝账户表和余额宝账户表显然不会在同一个数据库实例上，他们往往分布在不同的物理节点上，这个时候一定要避免使用本地事务。在跨库操作中，如果使用本地事务，往往会使本地事务失效，或者造成庞大的服务器开销，引发服务器死掉的极端影响。

 

 

本地事务：一般情况下，一个庞大的数据库表需要按照拆分字段进行分离，拆分成多个数据库实例，这个分离也是有规则的。比如按照用户USERID这个维度进行拆分，无论有多少个表，只要具有同一个拆分字段，那么具有相同USERID的数据都会存在于一个物理机器上面。通常情况下，我们在业务处理中，相当大的业务都会使用同样一个维度进行操作（因为一个人使用淘宝买东西，很多操作都是围绕这个人进行的，比如这个人的订单，这个人的资金，这个人的浏览记录......这是从购买者的角度上来看的。当然还有从商品的角度上面还看的业务，这个后面再说，我们可以先把从购买者角度上面的归集起来），张三操作的，只有这一个人，不会变成李四，这就决定了无论多少个表关联，都会存在于一个物理机上面，在不考虑事务时间的情况下，可以放心大胆的使用本地事务了。

 

异构索引表：一个人在淘宝买东西，从业务上面来看，不仅仅需要从购买者的角度来操作，还需要从商品的角度上面来操作。对于一个订单，假如有从购买者角度的表，我们非常容易的能够使用购买者ID定位到物理库位置，然后查询到这个订单。但是如果要通过商品或者卖家呢？直接查询的话，因为不知道购买者ID，只能进行全库查询，造成非常大的开销。因此，需要建立异构索引表，表结构和数据一模一样，只能分库主键为商品ID。当需要不同的业务时，就需要操作不同的异构索引表。

 

消息系统的分布式事务：上面说到了异构索引表，表数据是一样的，只是因为业务的需要，创建了不同维度的表。但是如何进行数据同步？使用本地事务肯定行不通，在多个数据库进行分布式事务，开销非常大的。只能通过消息系统的分布式事务解决。所有跨库操作都只能通过这种方式处理。

 

多个物理节点上面的本地事务：如果需要在多个物理节点使用Join操作，如果数据量不太大，就使用小表广播的方式。如果数据量太大了，那就需要在代码方面处理，尽量拆分为当个物理节点上面的事务操作。即分别单独在一个物理库上面执行事务，有多少个数据库，就执行多少次。

 

数据库连接资源：对于一个数据库连接，我们通常需要严格保证事务的时间，不能无限制的占用资源。因此，在本地事务中，尽量不要使用太大的事务，浪费数据库资源。