分布式事务2

独立消息服务方案

• 实现思路：
  1. 预发送消息：主动方应用系统预发送消息，由消息服务子系统存储消息，如果存储失败，那么也就无法进行业务操作。如果返回存储成功，然后执行业务操作。
  2. 执行业务操作：执行业务操作如果成功的时候，将业务操作执行成功的状态发送到消息服务子系统。消息服务子系统修改消息的标识为“可发送”状态。
  3. 发送消息到实时消息服务：当消息的状态发生改变的时候，立刻将消息发送到实时消息服务中。接下来，消息将会被消息业务的消费端监听到，然后被消费。
  4. 消息状态子系统：相当于定时任务系统，在消息服务子系统中定时查找确认超时的消息，在主动方应用系统中也去定时查找没有处理成功的任务，进行相应的处理。
  5. 消息消费：当消息被消费的时候，向实时消息服务发送ACK，然后实时消息服务删除消息。同时调用消息服务子系统修改消息为“被消费”状态。
  6. 消息恢复子系统：当消费方返回消息的时候，由于网络中断等其他原因导致消息没有及时确认，那么需要消息恢复子系统定时查找出在消息服务子系统中没有确认的消息。将没有被确认的消息放到实时消息服务中，进行重做，因为被动方应用系统的接口是幂等的。
• 优点：
  1. 消息服务独立部署，独立维护，独立伸缩。
  2. 消息存储可以按需选择不同的数据库来集成实现。
  3. 消息服务可以被相同的的使用场景使用，降低重复建设服务的成本。
  4. 从分布式服务应用设计开发角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖。
  5. 降低了业务系统与消息系统之间的耦合，有利于系统的扩展维护。
• 缺点：
  1. 一次消息发送需要两次请求。
  2. 主动方应用系统需要实现业务操作状态的校验与查询接口。

（七）、消息服务子系统的设计实现

示例消息数据表：

名称	数据类型	允许空	默认值	属性	释义
uuid	varchar(50)	No	—	unique	UUID
version	int(11)	No	0	—	版本号
editer	varchar(100)	Yes	NULL	—	修改者
creater	varchar(100)	Yes	NULL	—	创建者
edit_time	datetime	Yes	0000-00-00 00:00:00	—	最后修改时间
create_time	datetime	No	0000-00-00 00:00:00	—	创建时间
msg_id	varchar(50)	No	—	—	消息ID
msg_body	longtext	No	—	—	消息内容
msg_date_type	varchar(50)	Yes	—	—	消息数据类型
consumer_queue	varchar(100)	No	—	—	消费队列
send_times	int(6)	No	0	—	消息重发次数
is_dead	varchar(20)	No	—	—	是否死亡
status	varchar(20)	No	—	—	状态
remark	varchar(200)	Yes	—	—	备注
field0	varchar(200)	Yes	—	—	扩展字段0
field1	varchar(200)	Yes	—	—	扩展字段1
field2	varchar(200)	Yes	—	—	扩展字段2