一文替你解决分布式系统数据一致性的烦恼。

电玩女神 2024-03-25 20:25 17阅读 0赞

## 一：分布式消息怎么保证数据的最终一致性： ##

### 1.1 添加消息中间表方案： ###

为了保证原子性，我们可以变通一下，添加一个消息表，A不直接往消息中间件中发消息，而是把消息写入消息表，然后通过一个后台程序不断的把消息写入消息中间件。比如转账流程，如下图：

![format_png][]

这个后台应用会把消息表中的数据发送到消息中间件中，当然这里边我们要有一个字段标识出消息的状态，然后提供接口给消息中间件回调（ACK）来知道消息是否发送成功，如果失败就重试，可以保证：消息不会丢失顺序不乱但会有消息重复的情况，因为消息发送失败可能是写入失败，也可能是写入成功但响应失败，所以消息可能会重复，这个问题需要系统 **B来处理。**

### 1.2 那么系统B要考虑那些问题呢： ###

#### 1.2.1 消息丢失 ####

系统B从消息中间件中拿到消息，还没处理完就宕机了，这条消息怎么办？ 需要通过 **ACK机制处理，消费成功的发送ACK，对于没有ACK的消息，消息中间件会再次推送**。

#### 1.2.2 消息重复： ####

即使有ACK机制也存在消息重复的情况，比如B已经处理完一条消息，发ACK时失败了，那么这条消息就还会被推过来。还有就是上面说的后台程序发消息时可能重复。对于重复消息问题，可以加一个判重操作，记录处理成功的消息，每次收到消息时，先通过判重操作判断一下，如果重复了就不处理，实现幂等性。

判重操作 可以放一张表里，也可以放到redis里，存储一定时间，在相应时间里如果有重复消息进来，就认为消息重复，但是也要来考虑业务，比如订单有好多操作，可能要加各种场景的校验，为而不是简单的以订单号来判断重复，具体要细到什么维度就要看自己实际的真实业务来设定了。改造后流程图如下：

![format_png 1][]

## 二：分布式事务保证数据一致性 ##

常见分布式事务有 2PC、3PC、TCC、Saga、本地事务表、MQ事务消息、最大努力通知，我们这里重点介绍下主流的TCC和最大努力通知这两个

### 2.1 TCC ###

如果要用TCC 分布式事务的话：首先需要选择某种 TCC 分布式事务框架，各个服务里就会有这个 TCC 分布式事务框架在运行。

>  *  所以你原本的一个接口，要改造为 3 个逻辑，Try-Confirm-Cancel：先是服务调用链路依次执行 Try 逻辑。如果都正

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/ac0b14f6e6ba404e89907b2e852f00fa.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/a94aef50fbc14c2da644583d00519120.png