2022-04-12

Spring AMQP 的最佳实践：
三种签收模式：1.NONE 2.MANUAL 3.AUTO
NONE: 不做任何处理，相当于 rabbitmq 中的 autoAck，消息丢失后 broker 无法感知，不能采用
MANUAL: 手动模式，签收由用户处理，用户可以控制是否签收，若拒签后是否重新入列
AUTO: 自动模式，这里不代表 rabbitmq 中的 autoAck，这里的含义是：方法抛出异常时 nack，方法正常返回时 ack
注意：
许多文章说 AUTO 模式可能导致消息丢失，这种说法是错误的（可能与 autoAck 产生了混淆，笔者认为 AUTO 这个名字起得不好）。
AUTO 模式只是简化了用户 ack 的步骤，因为大多数情况下消费者没有发生异常时是 ack，其他情况（例如不用异常来处理是否重新入列、重新入列与业务逻辑挂钩）较少
死循环问题：死循环是指消费出现异常时重新如列，进入死循环 broker -> customer 异常 -> broker...
解决死循环的方案：
1.设置 default-requeue-rejected 参数为 false，在自动和手动模式下，发生异常时不入列
2.判断重试次数：
- 配置文件中设置 retry（全局的），当重试超过一定次数时，则不再重试
- 在业务逻辑中判断重试次数（局部的）
注意：retry 的优先级要高于 default-requeue-rejected
消息可靠投递：
生产者将消息持久化到数据库，设置状态标志位。设置到达 broker 的回调，在回调中修改标志位。定时任务来检查标志位以重新投递
消息可靠消费：
1.消息重试，消费时发生问题则重新入列，消息重试达到一定次数就停止（或者扔到死信队列）
2.消费失败则将消息丢入死信队列
对于需要重试的消息，可以采用以下的方式：
1.手动模式下，拒签且重新入列，此时消息回到队列头部
2.手动模式下，签收后将消息重新投递到队列尾部
3.配置文件中开启重试机制，同时适用于自动和手动模式
4.业务逻辑中判断重试次数
解决不幂等问题：为消息头添加唯一 id，存入 redis，在消费时从消息头拿出 id 进行幂等性检查
注意：重要的场景下必须要检查幂等性，启用消息重试时一定要检查幂等性
最佳实践（可能是）：
1.使用 AUTO 模式，若需要手动模式（一般是为了重新入列，消息重试）可以单独配置
2.配置 default-requeue-rejected 参数为 false 防止死循环
3.消费发生异常时，一般不需要重试，因为发生异常大多数情况是业务逻辑问题，重试了也没用。
需要重试的消息一般都是和业务逻辑相关，需要重试时则设置为手动模式在业务逻辑中判断

2022-04-12

推荐阅读更多精彩内容