消息中间件MQ-基于RabbitMQ分布式事务处理

一、回顾

1.消息中间件核心概念

消息中间件，本质就是接收数据、保存数据、发送数据的网络应用，常常应用在分布式架构系统中，实现业务服务（系统）之间拆分解耦、可靠性消息通信等协同处理。基于消息（数据）传递和消息队列，实现跨进程的通讯。

理解上可以认为是一个外置的queue队列，但需要协同不同的服务或系统，所以复杂的多，一般的消息中间件设计核心有5个：

• 支持的协议–解决通讯的问题
• 持久化机制–消息数据存入磁盘
• 消息分发机制–发布订阅（推送）、拉取、重发等，解决消息消费方式
• 高可用机制–支持集群部署，实现高可用的目的
• 高可靠机制–消息传输（发送和消费）和存储的可靠性保障

2.消息中间件RabbitMQ

什么是RabbitMQ

RabbitMQ是开源的AMQP（一种消息队列协议，适合金融行业，高可靠性）实现，在分布系统消息可靠性，支持集群，丰富的消息分发机制表现不错，客户端与spring集成紧密。可以使用managment插件实现web监控和管理。

RabbitMQ核心概念：

• exchange–负责接收消息和转发消息，支持4种转发机制
  支持fanout（副本发送到多个queue）/direct（routingkey完全匹配）/topic（模糊匹配routingkey）/headers(属性值匹配)不同绑定策略
• 队列Queue–消息的存储位置
• 路由bind–queue与exchange关系设置、定义routingkey与queue匹配，支持通配符
• 生产者–消息发送者
• 消费者–消息接收方
  
  RabbitMQ消息运作流程：
  

RabbitMQ的持久化和内存磁盘控制

支持消息持久化、exchange持久化、queue持久化，保证重启RabbitMQ数据不丢失。
消息持久化：生产发送消息时，可以设置该消息是持久化消息和非持久话消息
exchange持久化：创建exchange时可以指定是否持久化
queue持久化：创建队列queue是可以指定是否持久化

内存磁盘控制配置项：
最大内存：默认0.4（相对系统内存值），超过该阈值会阻塞生产者
内存换页比例：默认0.5，超过该阈值会把内存的数据保存到磁盘，清理内存，释放空间。
磁盘预警：默认50M，磁盘剩余空间低于阀值，停止换页和阻塞生产者，建议设置成系统的内存大小。默认10s检测一次。

RabbitMQ消息可靠性保证

消息发送可靠性：支持"最多一次"和“最少一次”
支持confirm机制，生产者设置监听回执。本地消息表+confirm机制可以重复发送失败的消息。

消息消费可靠性：支持开启手动ack机制（默认自动），消费者通过手动确认已经正确消费的消息，或者通过Nack告诉MQ重发或者放入死信队列。

二、基于RabbitMQ消息可靠性保证实现分布式事务

分布式事务是什么

即跨进程的事务，是跨系统的数据一致性问题，举个栗子，比如一个充值订单，有充值活动（满减）的情形，充值系统和活动系统属于两个服务。怎么保证充值操作后活动正确处理？这里就是一个分布式事务问题。充值系统通过RPC调用或者http调用活动系统接口的方式，不能保证两个系统的一致性问题（可能出现虽然RPC调用或者http调用失败，活动系统却业务处理了，但订单系统无法回滚活动系统的处理）。

RabbitMQ消息可靠性

RabbitMQ提供下面的机制：
可靠生产：保证消息发送到RabbitMQ
可靠消费：保证消息正确消费掉
最终保证多发方的数据一致性。

RabbitMQ处理外卖场景的分布式事务问题

1.可靠消息生产-记录消息发送
2.可靠消息生产-修改消息发送状态

利用RabbitMQ发布确认机制–MQ受理消息后会返回回执

如果在发送回执或者修改状态失败的情况，使用兜底方案：重复发送一定次数。

3.可靠消息消费处理-正常处理

开启手动ACK模式。由消费者控制消息的重复或者丢弃
保证幂等性。防止重复处理，一次操作对应一次正确的数据处理。

4.可靠消息消费处理-异常处理

消费处理失败，需要MQ再次重发给消费者。RabbitMQ提供Nack机制。

出现异常一般重复一定的次数，有消费者记录重试次数，并进行次数控制

可以采用redis内存数据库记录处理次数或时间。

4.可靠消息消费处理-超过重试次

消费处理失败，直接丢弃或者转移到死信队列中。

重复次数过多，一直失败，通过预警机制进行人工干预。

三、总结

使用消息中间件处理分布事务的关键是利用消息中间件的消息可靠性机制保证数据的一致性，但是有些MQ不支持（如kafka）。真实业务场景中可靠性保证需要依赖具体业务方实现，生产者消息confirm机制重发和消费者ack机制通知MQ重发，都需要生产者和消费者自己处理，消费时需要注意消息处理的幂等性。
这种处理分布式事务的方式：
优点：通用性、扩展性、方案成熟
缺点：只适合异步场景、有延迟需要业务容忍

尽量避免分布式事务
尽量将非核心事务采用异步处理