✅电商下单场景，如何设计一个数据一致性方案？

典型回答

假设有一个电商下单链路，上下游一共有5个系统，分别包括了订单系统、库存系统、积分系统、邮件通知系统、以及外部机构系统。

下单的时候，订单系统需要创建订单，库存系统需要扣减库存，积分系统需要给用户增加积分，邮件通知系统需要通知用户下单成功，外部机构系统给用户投保一笔运费险。

那么， 我们需要设计一个完整的一致性方案，该怎么做呢？

其实这个问题考察的就是分布式事务的运用。

✅常见的分布式事务有哪些？

常见的分布式事务有XA（2PC、3PC）、TCC、Seata、可靠消息最终一致性（本地消息表、MQ事务消息）、最大努力通知等，那么该如何在实际场景中选择具体哪种方案呢？

首先，我们看一下订单系统、库存系统、积分系统、邮件通知系统、以及外部机构系统这五个系统对一致性的要求。

为啥不都考虑强一致性呢？这样就可以保证数据一定一致，没什么隐患。

但是这样做成本太高了，也会让下单的成功率大大降低。我们想一想，在下单环节中，是不是只要订单创建成功、库存扣减成功，是不是就可以认为下单成功了。而至于其他的邮件通知、积分增加、其实是不应该影响到用户的下单流程的。我们不能说因为给你加积分失败了，所以下单就失败了吧。

所以，我们需要区别对待。那么就需要分析一下这些系统之间的一致性要求。

首先，订单系统和库存系统，这两个基本上是要求强一致性的，因为下单成功、库存必须扣减成功，否则就会超卖。库存扣减成功，订单也一定要创建成功，否则就会少卖。

所以，订单系统和库存系统对一致性的要求很高，基本上是强一致性的。

订单系统和积分系统之间的一致性要求是其次的， 因为首先我们要保障下单成功后积分增加一定要成功，但是并不要求一定要做到非常的实时，稍微有一点系统延迟，其实也是可以的。

订单系统和邮件通知系统之间的一致性要求就更弱了，用户下单成功后，发送邮件通知这个动作，其实即使是丢了，对订单以及用户体验来说，其实影响并不大。

而订单系统和外部机构系统之间的这个一致性保障的话就比较特殊了，按理来说其实是很高的，订单创建成功之后，运费险一定要投保成功，但是实际在技术实现上可以做一些特殊的设计，这个我们后面讲。

在分析完了以上几个系统之间的一致性要求之后，我们就可以具体的做方案的设计了。（以上分析并不绝对，不同的系统之间并不一样，有的电商对于积分增加要求不高，但是对于邮件通知要求高，所以，实际需要根据业务来确定。）

首先，订单和库存系统，基本上就是要强一致性，所以，可选的方案就是XA以及TCC，也就是需要通过协调者来整体控制系统之间的数据的一致性，做到要么都成功，要么都失败。

✅什么是TCC，和2PC有什么区别？

接下来订单系统和积分系统之间，我们其实可以考虑基于可靠消息实现最终一致性，因为他要求消息不能丢，并且可以接受延迟。所以可以给予MQ事务消息，或者本地消息表来实现。

✅如何基于MQ实现分布式事务

订单系统和邮件通知系统之间，我们就可以更加简单一点，用一个最大努力通知就行了，就算失败了也没关系。

✅什么是最大努力通知？

最后，至于订单系统和外部机构系统之间，理论上是要保证强一致性的，或者说怎么也得是秒级别的最终一致性。

但是实际情况是，外部机构的可用性和电商平台的可用性是完全天差地别的。很容易在投保的过程中失败，所以，这个地方一般的做法都是在协议上约定：

1、只要风控通过，投保一定成功。

2、可以先资金流理赔，然后再补齐信息流。

有了以上的约定之后，我们就可以把和外部系统之间的交互完全做成异步，基本上都是通过离线文件，每天同步一次，把当天的投保数据和理赔数据同步过去就可以了。

以上，就是一个基于实际业务场景，来选择分布式事务的方案的例子，这里面没提Seata的方案，其实Seata他并不是一个方案，其实是一堆方案的组合，因为他支持很多种模式，所以，以上的方案来说，也可以整体换成Seata，但是Seata的方案其实还是比较重的，所以一般小公司用的不多。但是如果要用的话，确实也是很好很强大方案。

✅什么是Seata？他有哪几种模式？

原文: https://www.yuque.com/hollis666/xkm7k3/qclfal9s63y5im9i