RabbitMQ如何保证消息幂等性

用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生副作用。
举个简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再相应客户端的时候也有可能出现网络中断或者异常等等。
1. RabbitMQ自动重试机制

消费者在消费消息的时候，如果消费者业务逻辑出现程序异常，这个时候我们如何处理？

使用重试机制，RabbitMQ默认开启重试机制。

实现原理：

• @RabbitHandler注解 底层使用Aop拦截，如果程序(消费者)没有抛出异常，自动提交事务
• 如果Aop使用异常通知拦截获取到异常后，自动实现补偿机制，消息缓存在RabbitMQ服务器端

注意：

• 默认会一直重试到消费者不抛异常为止，这样显然不好。我们需要修改重试机制策略，如间隔3s重试一次)

配置：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

spring:   rabbitmq:     # 连接地址     host: 127.0.0.1     # 端口号     port: 5672     # 账号     username: guest     # 密码     password: guest     # 地址(类似于数据库的概念)     virtual-host: /admin_vhost     # 消费者监听相关配置     listener:       simple:         retry:           # 开启消费者(程序出现异常)重试机制，默认开启并一直重试           enabled: true           # 最大重试次数           max-attempts: 5           # 重试间隔时间(毫秒)           initial-interval: 3000

2. 如何合理选择重试机制？

情况1: 消费者获取到消息后，调用第三方接口，但接口暂时无法访问，是否需要重试? 需要重试，可能是因为网络原因短暂不能访问

情况2: 消费者获取到消息后，抛出数据转换异常，是否需要重试? 不需要重试,因为属于程序bug需要重新发布版本

总结：对于情况2，如果消费者代码抛出异常是需要发布新版本才能解决的问题，那么不需要重试，重试也无济于事。应该采用日志记录+定时任务job进行健康检查+人工进行补偿

3. 调用第