04.其他方案

其他方案

1.事务状态表+调⽤⽅重试+接收⽅幂等

介绍

调⽤⽅维护⼀张事务状态表（或者说事务⽇志、⽇志流⽔），在每次调⽤之前，落盘⼀条事务流⽔，⽣成⼀个全局的事务ID

事务开始之前的状态是Begin，全部结束之后的状态是End。如果某个事务⼀直停留在Begin状态，则说明该事务没有执⾏完毕

然后有⼀个后台任务，扫描状态表，在过了某段时间后（假设1次事务执⾏成功通常最多花费30s），状态没有变为最终的状态，说明这条事务没有执⾏成功。于是重新调⽤系统的接口。保证这条流⽔的最终状态是End状态

事务状态表

补充说明

幂等问题：系统调用方和被调用方根据全局的事务ID做幂等操作，所以即使重复调⽤也没有关系
如果后台任务重试多次仍然不能成功，要为状态表加⼀个Error状态，通过⼈⼯介⼊⼲预
对于同步调⽤，调⽤⽅调⽤A或B失败的时候，可以重试三次。如果重试三次还不成功，则放弃操作，再交由后台任务后续处理

2.对账

介绍

所有的“过程”都必然产⽣“结果”，过程是我们所说的“事务”，结果就是业务数据。⼀个过程如果部分执⾏成功、部分执⾏失败，则意味着结果是不完整的。从结果也可以反推出过程出了问题，从⽽对数据进⾏修补，这就是“对账”的思路

例子

案例1

电商⽹站的订单履约系统。⼀张订单从“已⽀付”，到“下发给仓库”，到“出仓完成”。假定从“已⽀付”到“下发给仓库”最多⽤1个⼩时；从“下发给仓库”到“出仓完成”最多⽤8个⼩时。意味着只要发现1个订单的状态过了1个⼩时之后还处于“已⽀付”状态，就认为订单下发没有成功，需要重新下发，也就是“重试”。同样，只要发现订单过了8个⼩时还未出仓，这时可能会发出报警，仓库的作业系统是否出了问题……诸如此类

案例2

微博的关注关系。需要存两张表，⼀张是关注表，⼀张是粉丝表，这两张表各⾃都是分库分表的。假设A关注了B，需要先以A为主键进⾏分库，存⼊关注表；再以B为主键进⾏分库，存⼊粉丝表。也就是说，⼀次业务操作，要向两个数据库中写⼊两条数据，如何保证原⼦性？

案例3

电商的订单系统也是分库分表的。订单通常有两个常⽤的查询维度，⼀个是买家，⼀个是卖家。如果按买家分库，按卖家查询就不好做；如果按卖家分库，按买家查询就不好做。这种通常会把订单数据冗余⼀份，按买家进⾏分库分表存⼀份，按卖家再分库分表存⼀份。和案例2存在同样的问题：⼀个订单要向两个数据库中写⼊两条数据，如何保证原⼦性？