可靠消息的最终一致性解决方案.docx

可靠消息的最终一致性解决方案
 
   
 
 
 
 
 
 
 
     
 
 
 
 
 
可靠消息的最终一致性解决方案
本地消息服务的方案
实现思路
消息生产者通过业务操作完成数据的   
 
   
可靠消息的最终一致性解决方案
 
   
 
 
 
 
 
 
 
     
 
 
 
 
 
可靠消息的最终一致性解决方案
本地消息服务的方案
实现思路
消息生产者通过业务操作完成数据的操作，在准备发送消息的时候，先将消息存储一份，然后发送给消息中间件集群。
消息消费者监听消息中间件中的消息，消费者消息处理之后，调用消息生产者接口，进行消息消费确认。
消息生产者接受消息确认之后，删除消息数据。
消息查询服务查询消息在被接收之后没有返回消息消费确认，那么就通过消息恢复系统进行消息重新发送。
架构图
image
优点
消息时效性比较高
从应用设计角度实现了消息的可靠性，弱化了对 MQ中间件特性的依赖。
方案比较轻量级，容易实现。
缺点
与具体的业务场景强耦合，不可以其他业务场景共用。
消息数据与业务数据同步，占用业务系统资源
业务系统在使用关系型数据的情况下，消息服务性能会受到关系型数据库的限制。
独立消息服务实现方案
实现思路
预发送消息：消息生产者系统预先发送消息，由消息服务子系统负责消息存储，如果存储失败，那么消息生产者不能进入业务操作，如果消息存储成功，消息生产者模块可进行后续业务操作。
执行业务操作：执行业务操作成功后，将业务操作执行的状态，发送到消息服务子系统，消息服务子系统性消息的标识为 “可发送” 状态。
发送消息到 MQ 集群服务：宕消息的状态发生改变，变成可发送的时候，立即将消息发生到 MQ 集群中，消息通过 MQ 集群被消费者监听到，被消费处理。
消息状态子服务：定时任务系统，在消息服务子系统中，定时查找消息中定时查找确认超时的消息，在主动方应用系统中去定时查找确认超时的消息，并且去消息生产者方查询没有处理成功的任务，进行相应处理。
消息恢复子系统：当消息生产者发送消息的时候，出现了网络中断等原因，出现了还没有及时确认,那么需要消息恢复子系统定时查出消息中未确认的消息，将未确认的消息进行消息重发，这也需要消息消费者皆是幂等的。
优点
消息服务独立部署，独立维护，独立伸缩。
消息存储可以选择不同的数据库来实现
消息服务可以被相同的使用昌吉使用，降低重复建设服务成本
从分布式服务应用设计角度时间消息数据的可靠性，消息数据的可靠性，弱化了对 MQ 中间件的依赖。
缺点
一次那个消息发生需要两次请求
消息生产者需要显示业务状态校验和查询接口。
实现架构
image
表结构设计
名称
数据类型
允许空
默认值
属性
释义
uuid
varchar(50)
No
—
unique
UUID
version
int(11)
No
0
—
版本号
editer
varchar(100)
Yes
NULL
—
修改者
creater
varchar(1