对网站建设的维护百度识图查图片
分布式事务八_可靠消息最终一致性方案
更多干货
- 分布式事务处理一
- 分布式事务二
- 分布式事务处理三
- 分布式事务四_基于可靠消息的最终一致性
- 分布式事务五_基于可靠消息的最终一致性_异常流程
- 分布式事务六_常规MQ队列
- 分布式事务七_幂等性设计
- 分布式事务八_可靠消息最终一致性方案
- 分布式事务九_基于可靠消息的最终一致性代码
- 分布式事务10_最大努力通知形势
- 柔性事务解决方案：TCC（两阶段型、补偿型）
- 支付宝 分布式事务服务 DTS 一
- 分布式事务服务 DTS二
- 分布式事务服务 DTS三
- 支付宝 分布式事务服务 DTS四
面临的问题
通过前面文章的分析可以得到一下结论
- 现成的MQ中间件产品不支持消息发送一致性流程（先进存储，在被确认后才能发送的2步流程）
- 直接改造或者开发MQ中间件的难度大
基于本地消息服务的设计
实现思路
- 主动方应用系统加入消息存储模块。即业务操作和消息存储与发送在同一个本地事务中。先将需要发送的消息存储在本地数据库，设置其状态为代发送
- 将消息数据中为待发送的消息发送到MQ,MQ 推送到其他应用系统处理
- 其他应用系统处理结束后回调主动发系统并修改消息的状态或者删除消息
- 消息恢复系统：用来查询那些超时未处理状态的消息并设置延时发送
优点
1.消息时效性比较高 2.从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖 3.方案轻量，容易实现
独立消息服务的设计
实现思路
与上面的方案相比独立实现了消息服务子系统
主动发应用发送预发送消息，消息服务子系统 存储预发送消息状态未预发送，并返回操作结果
主动发应用在预发送消息成功的前提下开始进行业务操作
主动发应用发送业务操作结果给消息系统
消息系统确认并发送消息，并设置消息状态为发送中
MQ将消息转发到其他业务系统
消息状态确认子系统 查询消息服务子系统中状态还是预发送的超时消息，并查询此消息在主动方应用系统的处理情况。如果主动发业务操作失败则删除该消息。如果主动方业务操作成功则修改状态为待发送，且将信息发送到MQ
消息恢复系统：用来查询那些超时未处理状态的消息并设置延时发送
优点:
- 消息服务独立部署、独立维护、独立伸缩
- 消息存储可以按需选择不同的数据库来集成实现
- 消息服务可以被相同的使用场景公用，降低重复建设消息服务的成本
- 从应用（分布式服务）设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖与MQ中间件，弱化了对MQ中间件特性的依赖
- 降低了业务系统与消息系统间的耦合，有利于系统的扩展维护
可靠消息最终一致性方案的优化
- 数据库: Redis(可靠性、可用性、性能)
- 特别注意持久化的配置 appendfsynnc always 只要有新添加的数据就将数据缓存同步到磁盘
- 消息日志表：适用于被动方应用业务的幂等性判断比较麻烦或比较消耗性能的情况，但会增加一定的开发工作量等
- 分布式调度
- 独立业务使用独立消息服务（提高性能、隔离解耦、但增加维护成本和工作量）
弊端/局限
- 一次消息发送需要两次请求
- 主动发应用系统需要实现业务操作状态校验接口