分布式事务初学

 

 

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

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

3、消息中间件返回消息持久化结果（成功/失败），主动方应用根据返回结果进行判断如何进行业务操作处理：

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

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

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

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

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

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

6、前面的正向流程都成功后，向被动方应用投递消息；

七、待解决问题

消息发送一致性方案的正向流程是可行的，但异常流程怎么处理呢？消息发送到消息中间件中能得到保障了，但消息的准确消费（投递）又如何保障呢？有没有支持这种发送一致性流程的现成消息中间件？

 

可靠消息最终一致性方案的优化

数据库: Redis(可靠性、可用性、性能)

特别注意持久化的配置 appendfsynnc always 只要有新添加的数据就将数据缓存同步到磁盘

消息日志表：适用于被动方应用业务的幂等性判断比较麻烦或比较消耗性能的情况，但会增加一定的开发工作量等

分布式调度

独立业务使用独立消息服务（提高性能、隔离解耦、但增加维护成本和工作量）

弊端/局限

一次消息发送需要两次请求

主动发应用系统需要实现业务操作状态校验接口

 

 

 

 

实现思路

1、与上面的方案相比独立实现了消息服务子系统

2、主动发应用发送预发送消息，消息服务子系统 存储预发送消息状态未预发送，并返回操作结果

3、主动发应用在预发送消息成功的前提下开始进行业务操作

4、主动发应用发送业务操作结果给消息系统

5、消息系统确认并发送消息，并设置消息状态为发送中

6、MQ将消息转发到其他业务系统

7、消息状态确认子系统查询消息服务子系统中状态还是预发送的超时消息，并查询此消息在主动方应用系统的处理情况。如果主动发业务操作失败则删除该消息。如果主动方业务操作成功则修改状态为待发送，且将信息发送到MQ

8、消息恢复系统：用来查询那些超时未处理状态的消息并设置延时发送

优点:

消息服务独立部署、独立维护、独立伸缩

消息存储可以按需选择不同的数据库来集成实现

消息服务可以被相同的使用场景公用，降低重复建设消息服务的成本

从应用（分布式服务）设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖与MQ中间件，弱化了对MQ中间件特性的依赖

降低了业务系统与消息系统间的耦合，有利于系统的扩展维护