一、先扔一张图

说明:

本文涵盖了关于RabbitMQ很多方面的知识点, 如:

• 消息发送确认机制
• 消费确认机制
• 消息的重新投递
• 消费幂等性, 等等

这些都是围绕上面那张整体流程图展开的, 所以有必要先贴出来, 见图知意

二、实现思路

1. 简略介绍 163 邮箱授权码的获取
2. 编写发送邮件工具类
3. 编写 RabbitMQ 配置文件
4. 生产者发起调用
5. 消费者发送邮件
6. 定时任务定时拉取投递失败的消息, 重新投递
7. 各种异常情况的测试验证
8. 拓展: 使用动态代理实现消费端幂等性验证和消息确认 (ack)

三、项目介绍

1. springboot版本2.1.5.RELEASE, 旧版本可能有些配置属性不能使用, 需要以代码形式进行配置
2. RabbitMQ版本3.7.15
3. MailUtil: 发送邮件工具类
4. RabbitConfig: rabbitmq 相关配置
5. TestServiceImpl: 生产者, 发送消息
6. MailConsumer: 消费者, 消费消息, 发送邮件
7. ResendMsg: 定时任务, 重新投递发送失败的消息

四、各种异常情况测试

步骤一罗列了很多关于 RabbitMQ 的知识点, 很重要, 很核心, 而本文也涉及到了这些知识点的实现, 接下来就通过异常测试进行验证 (这些验证都是围绕本文开头扔的那张流程图展开的, 很重要, 所以, 再贴一遍)

1. 验证消息发送到 Exchange 失败情况下的回调, 对应上图P -> X

如何验证? 可以随便指定一个不存在的交换机名称, 请求接口, 看是否会触发回调

发送失败, 原因: reply-code=404, reply-text=NOT_FOUND - no exchange 'mail.exchangeabcd' in vhost '/', 该回调能够保证消息正确发送到 Exchange, 测试完成

1. 验证消息从 Exchange 路由到 Queue 失败情况下的回调, 对应上图X -> Q

同理, 修改一下路由键为不存在的即可, 路由失败, 触发回调

发送失败, 原因: route: mail.routing.keyabcd, replyCode: 312, replyText: NO_ROUTE

1. 验证在手动 ack 模式下, 消费端必须进行手动确认 (ack), 否则消息会一直保存在队列中, 直到被消费, 对应上图Q -> C

将消费端代码channel.basicAck(tag, false);// 消费确认注释掉, 查看控制台和 rabbitmq 管控台

可以看到, 虽然消息确实被消费了, 但是由于是手动确认模式, 而最后又没手动确认, 所以, 消息仍被 rabbitmq 保存, 所以, 手动 ack 能够保证消息一定被消费, 但一定要记得basicAck

1. 验证消费端幂等性

接着上一步, 去掉注释, 重启服务器, 由于有一条未被 ack 的消息, 所以重启后监听到消息, 进行消费, 但是由于消费前会判断该消息的状态是否未被消费, 发现status=3, 即已消费, 所以, 直接return, 这样就保证了消费端的幂等性, 即使由于网络等原因投递成功而未触发回调, 从而多次投递, 也不会重复消费进而发生业务异常

1. 验证消费端发生异常消息也不会丢失

很显然, 消费端代码可能发生异常, 如果不做处理, 业务没正确执行, 消息却不见了, 给我们感觉就是消息丢失了, 由于我们消费端代码做了异常捕获, 业务异常时, 会触发: channel.basicNack(tag, false, true);, 这样会告诉 rabbitmq 该消息消费失败, 需要重新入队, 可以重新投递到其他正常的消费端进行消费, 从而保证消息不被丢失

测试: send 方法直接返回 false 即可 (这里跟抛出异常一个意思)

可以看到, 由于channel.basicNack(tag, false, true), 未被 ack 的消息 (unacked) 会重新入队并被消费, 这样就保证了消息不会走丢

1. 验证定时任务的消息重投

实际应用场景中, 可能由于网络原因, 或者消息未被持久化 MQ 就宕机了, 使得投递确认的回调方法ConfirmCallback没有被执行, 从而导致数据库该消息状态一直是投递中的状态, 此时就需要进行消息重投, 即使也许消息已经被消费了

定时任务只是保证消息 100% 投递成功, 而多次投递的消费幂等性需要消费端自己保证

我们可以将回调和消费成功后更新消息状态的代码注释掉, 开启定时任务, 查看是否重投

可以看到, 消息会重投 3 次, 超过 3 次放弃, 将消息状态置为投递失败状态, 出现这种非正常情况, 就需要人工介入排查原因

五、拓展: 使用动态代理实现消费端幂等性验证和消费确认 (ack)

不知道大家发现没有, 在MailConsumer中, 真正的业务逻辑其实只是发送邮件mailUtil.send(mail)而已, 但我们又不得不在调用send方法之前校验消费幂等性, 发送后, 还要更新消息状态为 "已消费" 状态, 并手动 ack, 实际项目中, 可能还有很多生产者 - 消费者的应用场景, 如记录日志, 发送短信等等, 都需要 rabbitmq, 如果每次都写这些重复的公用代码, 没必要, 也难以维护, 所以, 我们可以将公共代码抽离出来, 让核心业务逻辑只关心自己的实现, 而不用做其他操作, 其实就是 AOP

为达到这个目的, 有很多方法, 可以用 spring aop, 可以用拦截器, 可以用静态代理, 也可以用动态代理, 在这里, 我用的是动态代理

目录结构如下:

核心代码就是代理的实现, 这里就不把所有代码贴出来了, 只是提供一个思路, 我们要尽可能地把代码写的更简洁更优雅

六、总结

发送邮件其实很简单, 但深究起来其实有很多需要注意和完善的点, 一个看似很小的知识点, 也可以引申出很多问题, 甚至涉及到方方面面, 这些都需要自己踩坑