(这些验证都是围绕本文开头扔的那张流程图展开的, 很重要, 所以, 再贴一遍)
1.验证消息发送到Exchange失败情况下的回调, 对应上图P -> X
如何验证?..., 这样就保证了消费端的幂等性, 即使由于网络等原因投递成功而未触发回调, 从而多次投递, 也不会重复消费进而发生业务异常
5.验证消费端发生异常消息也不会丢失
很显然, 消费端代码可能发生异常, 如果不做处理...(tag, false, true), 未被ack的消息(unacked)会重新入队并被消费, 这样就保证了消息不会走丢
6.验证定时任务的消息重投
实际应用场景中, 可能由于网络原因, 或者消息未被持久化...投递成功, 而多次投递的消费幂等性需要消费端自己保证
我们可以将回调和消费成功后更新消息状态的代码注释掉, 开启定时任务, 查看是否重投
可以看到, 消息会重投3次, 超过3次放弃, 将消息状态置为投递失败状态..."已消费"状态, 并手动ack, 实际项目中, 可能还有很多生产者-消费者的应用场景, 如记录日志, 发送短信等等, 都需要rabbitmq, 如果每次都写这些重复的公用代码, 没必要, 也难以维护,