微服务架构之最终一致性设计概述

Posted 2021-04-14 家园叮咚

一、可靠消息最终一致（异步确保型）

实现

   业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送

消息

业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期

找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根

据消息ID或消息内容确定该消息是否有效 

约束

   被动方的处理结果不影响主动方的处理结果,被动方的消息处理操作是幂等操作

成本

   可靠消息系统建设成本

   一次消息发送需要两次请求，业务处理服务需实现消息状态回查接口

优点、适用范围

消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合

需要实现的服务

可查询操作、幂等操作

方案特点

兼容所有实现AMQP标准的MQ中间件

确保业务数据可靠的前提下，实现业务数据的最终一致（理想状态下基本是准实时一致）

适用

1、对应支付系统会计异步记账业务

2、普通的积分账户增加积分的服务

   分布式部署环境下，需要通过网络进行通讯，就引入了数据传输的不确定性，也就是CAP理论中的P（分区容错性的问题），但是我们需要保证消息尽可能的一致

消息发送一致性的概念：是指产生消息的业务动作与消息发送的一致。

（也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息）

举例

1、如果业务操作成功，执行消息发送前应用故障，消息发不出去，导致消息丢失（订单系统与积分系统的数据不一致）; 

2、如果业务操作成功，应用正常，但消息系统故障或网络故障，也会导致消息发不出去（订单系统与积分系统的数据不一致）;

2、那消息投递如何做到可靠呢？

看看下图的思路：

1. 主动方应用先把消息发给消息中间件，消息状态标记为“待确认”；

2. 消息中间件收到消息后，把消息持久化到消息存储中，但并不向被动方应用投递消息；

3. 消息中间件返回消息持久化结果（成功/失败），主动方应用根据返

回结果进行判断如何进行业务操作处理：

a) 失败：放弃业务操作处理，结束（必要时向上层返回失败结果）；

b) 成功：执行业务操作处理；

4. 业务操作完成后，把业务操作结果（成功/失败）发送给消息中间件；

5. 消息中间件收到业务操作结果后，根据业务结果进行处理；

a) 失败：删除消息存储中的消息，结束；

b) 成功：更新消息存储中的消息状态为“待发送（可发送）”，紧接 着执行消息投递；

6. 被动方应用监听并接收“待发送”状态的消息，执行业务处理；

7. 业务处理完成后，向消息中间件发送ACK，确认消息已经收到（消息 )

中间件将从队列中删除该消息）

当然除了正向的流程以外还有异常的处理流程，也要保证可靠性

一、从主动方应用的角度

2.从中间件的角度

3.异常情况的总结处理

那有没有支持这种发送一致性流程的现成消息中间件？我们下回接着说。