保证分布式系统数据一致性的6种方案

java

https://mp.weixin.qq.com/s?__biz ... bd3e5d&scene=21


------------eBay 模式 BASE------
eBay 模式 BASE (basically available, soft state, eventually consistent)
如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。解决方法，将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性，增加一个更新记录表 updates_applied 来记录已经处理过的消息。
基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。


在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。


通过以上方法，达到了分布式系统的最终一致性。

---------- 去哪儿网分布式事务方案-----------
1. 优先使用异步消息。
一种方式是业务逻辑保证幂等。
另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。
2. 有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。
将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性。

----------蘑菇街交易创建过程中的分布式一致性方案------
试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。
所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。

----------
DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。
DTS 框架有如下特性：


    最终一致：事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。

    协议简单：DTS 定义了类似 2PC 的标准两阶段接口，业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。

    与 RPC 服务协议无关：在 SOA 架构下，一个或多个 DB 操作往往被包装成一个一个的 Service，Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上，与底层协议无关。

    与底层事务实现无关： DTS 是一个抽象的基于 Service 层的概念，与底层事务实现无关，也就是说在 DTS 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列存数据库 HBase，只要将对其的操作包装成 DTS 的参与者，就可以接入到 DTS 事务范围内。
实现
    一个完整的业务活动由一个主业务服务与若干从业务服务组成。

    主业务服务负责发起并完成整个业务活动。

    从业务服务提供 TCC 型业务操作。

    业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的 confirm 操作，在业务活动取消时调用所有两阶段事务的 cancel 操作。”


与 2PC 协议比较

    没有单独的 Prepare 阶段，降低协议成本
    系统故障容忍度高，恢复简单