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

灰太狼 2023-09-25 21:54 23阅读 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 逻辑。如果都正常的话，TCC 分布式事务框架推进执行 Confirm 逻辑，完成整个事务。如果

[format_png]: https://img-blog.csdnimg.cn/img_convert/2e992110b7813de46773a8dcdabae755.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/6a7057f8fd4afe3ed2bc93128b16d2d1.webp?x-oss-process=image/format,png