在开发或软件架构的过程中，经常会遇到数据一致性的问题。尤其是在微服务架构下，每个微服务都有自己的数据库，导致微服务架构的系统不能简单地满足 ACID，我们就需要寻找微服务架构下的数据一致性解决方案。
传统情况下，当一个事务要跨越多个分布式服务时，开发者想到的第一个方案就是两阶段提交——2PC。在这个过程中，事务协调者（事务管理器）给每个参与者（资源管理器）发送 Prepare 消息，如果参与者有可用资源，对数据加锁，如果所有参与者都返回成功，就执行第二阶段，否则，执行回滚操作。
由于数据库通常比业务服务更难扩容，而两阶段提交需要依赖于数据库实现，并且对数据加锁，所以性能较低，应用并不是十分广泛。
那么，如何保证微服务架构中的数据一致性？华为云 PaaS 团队架构师王启军老师提到了几个方面：
1. 可靠事件通知模式
该模式下，一种通知模式是同步事件，即主服务完成后将结果通过事件（以消息队列为主）传递给服务，进而完成业务流程，达到主服务与服务间的消息一致性。另一种是异步事件，即业务服务和事件服务解耦，需要将提交失败的事件进行重试，目前业界多数采用本地消息表 +MQ 的方式来进行重试，但也因此对数据库产生压力。
2. 使用 Saga 保证微服务的最终一致性
Saga 将一个跨服务的事务拆分成多个事务，每个子事务都需要定义一个对应的补偿操作。通过异步的模式来完成整个 Saga 流程。具体操作是将项目创建流程拆分成多个 Saga，并为 Saga 分配一个事务管理器。当服务启动时，会将服务中所有的 SagaTask 注册到管理器中。在业务执行时，执行状态可以通过事务管理器进行查看。
3. TCC/Try Confirm Cancel 模式
在 TCC 模式下，当一个服务提交失败时，可以做到完全补偿，且在补偿后不留下补偿记录。这样可以在业务层处理时，平衡数据库的压力。但其代价也在于增加了业务的复杂度，需要提供相应的 Try、Confirm、Cancel 接口等。
4. 华为云分布式事务服务—DTM
DTM 是华为云分布式事务管理中间件，它的具体步骤是，先由实物发起者向 DTM 集群申请注册一个全局事务的 ID，并透传到所调用的事务参与者中，事务参与者利用得到的 ID 向 DTM 集群注册申请一个分事务 ID，在事务参与者完成自身业务逻辑后，将结果上传至 DTM 集群，并示意分支事务结束，在后续完成 TCC 二阶段后，DTM 集群通稿事务发起者全局事务结束。具体流程如下图所示：
最后，王启军老师总结：不是所有的地方对一致性要求都这么高，要根据自己的业务需求来选择一致性的模型。一致性没有绝对的，更严格的一致性只是降低概率而已，更高的一致性需要更高的成本，需要企业综合考虑。
除了一致性话题之外，王老师将在 12 月 7 日北京 ArchSummit 全球架构师峰会上分享《反应式微服务框架 Apache ServiceComb 设计思想》的话题，介绍 Reactive 编程模型带来的好处，以及在微服务架构下，如何快速建立 Reactive 架构。
感兴趣可以点击 https://archsummit.infoq.cn/2019/beijing/track 查看官网了解更多议题内容。9 折倒计时20天，团购更优惠哦～详情联系票务经理灰灰：15600537884（同微信）