MQ 消息幂等性保证
1. 什么是幂等性
在程序开发中，是指同一个业务，执行一次或多次对业务状态的影响是一致的。例如：
- 根据 id 删除数据
- 查询数据
在实际业务中，避免不了出现用户连续点击退款、重复点击删除等情况，这种情况下，就需要对多个消息进行处理，避免短时间内多次执行相同业务（类似于防抖）。
如：
-
幂等性操作
- 查询
- 根据条件删除
- 更新
-
非幂等性操作
-
增加：多次执行，会插入多条数据
即使使用唯一约束，也只能解决一部分情况
-
更新
-
解决方案：
- 唯一消息 ID
- 业务状态判断
2. 唯一消息 ID
这个思路非常简单：
- 每一条消息都生成一个唯一的 id，与消息一起投递给消费者。
- 消费者接收到消息后处理自己的业务，业务处理成功后将消息 ID 保存到数据库或 Redis
- 如果下次又收到相同消息，去数据库或 Redis 查询判断是否存在，存在则为重复消息放弃处理。
我们该如何给消息添加唯一 ID 呢？
其实很简单，SpringAMQP 的 MessageConverter 自带了 MessageID 的功能，我们只要开启这个功能即可。
以 Jackson 的消息转换器为例：
@Bean
public MessageConverter messageConverter() {// 1. 定义消息转换器Jackson2JsonMessageConverter jjmc = new Jackson2JsonMessageConverter();// 2. 配置自动创建消息 id，用于识别不同消息，也可以在业务中基于 ID 判断是否是重复消息jjmc.setCreateMessageIds(true);return jjmc;
}
然后再使用自动装配，将其注入 Spring 中即可
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\com....messageConverter
3. 业务判断
业务判断就是基于业务本身的逻辑或状态来判断是否是重复的请求，不同的业务场景判断的思路也不一样。
相比较而言，使用唯一消息 ID 的方案需要操作数据库或 Redis 保存消息 ID，所以更推荐使用业务判断的方案。
以支付修改订单的业务为例：
@Override
public void markOrderPaySuccess(Long orderId) {// UPDATE `order` SET status = ? , pay_time = ? WHERE id = ? AND status = 1lambdaUpdate().set(Order::getStatus, 2).set(Order::getPayTime, LocalDateTime.now()).eq(Order::getId, orderId).eq(Order::getStatus, 1) // 添加对业务状态的判断，只有为未支付状态的订单才能支付.update();
}
4. 业务补偿
虽然利用各种机制尽可能增加了消息的可靠性，但也不好说能保证消息 100% 的可靠。万一真的 MQ 通知失败该怎么办呢？有没有其它补偿方案，能够确保订单的支付状态一致呢？
其实思想很简单：既然 MQ 通知不一定发送到交易服务，那么交易服务就必须自己主动去查询支付状态。这样即便支付服务的 MQ 通知失败，我们依然能通过主动查询来保证订单状态的一致。
图中黄色线圈起来的部分就是 MQ 通知失败后的补偿处理方案，由交易服务自己主动去查询支付状态。
