九、如何保障微服务架构下的数据一致性
以电商平台为例，当用户下单并支付后，系统需要修改订单的状态并
且增加用户积分。由于系统采用的是微服务架构，分离出了支付服务、订 单服务和积分服务，每个服务都有独立数据库做数据存储。当用户支付成 功后，无论是修改订单状态失败还是增加积分失败，都会 造成数据的不 一致。
然而微服务架构下，每个微服务都有自己的数据库，导致微服务架构 的系统不能简单地满足 ACID，我们就需要寻找微服务架构下的数据一致性解决方案：
CAP是指在一个分布式系统下，包含三个要素：：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），并且 三者不 可得兼。
C:所有数据变动都是同步的
A：即在可以接受的时间范围内正确的相应用户请求
P：分区容错性，即某节点或网络分区故障时，系统仍能提供满足一致性和可用性的服务。
在分布式系统下，为了保证模块的分区容错性，只能在数据强一致性和可用性之间做平衡。具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或者手动补偿后能够达到最终的一致。
分享我们是如何保证微服务架构的数据一致性的：
1、可靠消息最终一致性（适用于跨平台技术栈不统一的场景）利用MQ组件实现的二阶段提交，涉及三个模块：
A、上游应用，执行业务并发送MQ消息
B、可靠消息服务和MQ消息组件，协调上下游消息的传递，并确保上下游数据的一致性。
C、下游应用，监听MQ的消息并执行自身业务。
涉及三个模块：主业务、从业务、活动管理器
1、主业务服务分别调用所有从业务服务的try操作，并在活动管理器中记录所有从业务服务。当所有从业服务try成功或者某个从业服务try失败时，进入第二阶段。
2、活动管理器根据第一阶段从业服务的try结果来执行confirm或cancel操作。如果第一阶段所有从业务服务都try成功，则协作者调用所有从业服务的confirm操作，否则，调用所有从业务服务的cancel操作。
Confirm 失败：则回滚所有 confirm 操作并执行 cancel 操作。
Cancel 失败：从业务服务需要提供自动 cancel 机制，以保证 cancel 成功。
参考地址：
张队长文章：https://mp.weixin.qq.com/s/UIFjm7W6bDfdmjpeMVJtqA
文档参考地址：《从 0 开始的微服务架构》
文档下载地址：《从 0 开始的微服务架构》
asp.net Core 交流群：787464275 欢迎加群交流
如果您认为这篇文章还不错或者有所收获，您可以点击右下角的【推荐】按钮精神支持，因为这种支持是我继续写作，分享的最大动力！