十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
咸宁ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联建站的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!
说明:
SpringBoot
SpringBoot是由Pivotal团队在2013年开始研发、2014年4月发布第一个版本的全新开源的轻量级框架。它基于Spring4.0设计,不仅继承了Spring框架原有的优秀特性,而且还通过简化配置来进一步简化了Spring应用的整个搭建和开发过程。另外SpringBoot通过集成大量的框架使得依赖包的版本冲突,以及引用的不稳定性等问题得到了很好的解决。
SpringBoot特征
(1)可以创建独立的Spring应用程序,并且基于其Maven或Gradle插件,可以创建可执行的JARs和WARs;
(2)内嵌Tomcat或Jetty等Servlet容器;
(3)提供自动配置的“starter”项目对象模型(POMS)以简化Maven配置;
(4)尽可能自动配置Spring容器;
(5)提供准备好的特性,如指标、健康检查和外部化配置;
(6)绝对没有代码生成,不需要XML配置。
MQ全称为Message Queue, 消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息(针对应用程序的数据)来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。其中较为成熟的MQ产品有IBM WEBSPHERE MQ等等。
简略介绍163邮箱授权码的获取
编写发送邮件工具类
编写RabbitMQ配置文件
生产者发起调用
消费者发送邮件
定时任务定时拉取投递失败的消息, 重新投递
各种异常情况的测试验证
拓展: 使用动态代理实现消费端幂等性验证和消息确认(ack)
springboot
版本2.1.5.RELEASE
, 旧版本可能有些配置属性不能使用, 需要以代码形式进行配置
RabbitMQ
版本3.7.15
MailUtil
: 发送邮件工具类
RabbitConfig
: rabbitmq相关配置
TestServiceImpl
: 生产者, 发送消息
MailConsumer
: 消费者, 消费消息, 发送邮件
ResendMsg
: 定时任务, 重新投递发送失败的消息
163邮箱授权码的获取, 如图:
该授权码就是配置文件spring.mail.password
需要的密码
2.pom
3.rabbitmq
、邮箱配置
说明:
password
即授权码,username
和from
要一致
4.表结构
说明: exchange routing_key
字段是在定时任务重新投递消息时需要用到的
5.MailUtil
6.RabbitConfig
@Configuration@Slf4jpublic class RabbitConfig { @Autowired private CachingConnectionFactory connectionFactory; @Autowired private MsgLogService msgLogService; @Bean public RabbitTemplate rabbitTemplate() { RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory); rabbitTemplate.setMessageConverter(converter()); // 消息是否成功发送到Exchange rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> { if (ack) { log.info("消息成功发送到Exchange"); String msgId = correlationData.getId(); msgLogService.updateStatus(msgId, Constant.MsgLogStatus.DELIVER_SUCCESS); } else { log.info("消息发送到Exchange失败, {}, cause: {}", correlationData, cause); } }); // 触发setReturnCallback回调必须设置mandatory=true, 否则Exchange没有找到Queue就会丢弃掉消息, 而不会触发回调 rabbitTemplate.setMandatory(true); // 消息是否从Exchange路由到Queue, 注意: 这是一个失败回调, 只有消息从Exchange路由到Queue失败才会回调这个方法 rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> { log.info("消息从Exchange路由到Queue失败: exchange: {}, route: {}, replyCode: {}, replyText: {}, message: {}", exchange, routingKey, replyCode, replyText, message); }); return rabbitTemplate; } @Bean public Jackson2JsonMessageConverter converter() { return new Jackson2JsonMessageConverter(); } // 发送邮件 public static final String MAIL_QUEUE_NAME = "mail.queue"; public static final String MAIL_EXCHANGE_NAME = "mail.exchange"; public static final String MAIL_ROUTING_KEY_NAME = "mail.routing.key"; @Bean public Queue mailQueue() { return new Queue(MAIL_QUEUE_NAME, true); } @Bean public DirectExchange mailExchange() { return new DirectExchange(MAIL_EXCHANGE_NAME, true, false); } @Bean public Binding mailBinding() { return BindingBuilder.bind(mailQueue()).to(mailExchange()).with(MAIL_ROUTING_KEY_NAME); }}
7.TestServiceImpl
生产消息
8.MailConsumer消费消息, 发送邮件
说明: 其实就完成了3件事: 1.保证消费幂等性, 2.发送邮件, 3.更新消息状态, 手动ack
9.ResendMsg
定时任务重新投递发送失败的消息
OK, 目前为止, 代码准备就绪, 现在进行正常流程的测试
发送请求:
后台日志:
数据库消息记录:
状态为3, 表明已消费, 消息重试次数为0, 表明一次投递就成功了
查看邮箱
发送成功
步骤一罗列了很多关于RabbitMQ的知识点, 很重要, 很核心, 而本文也涉及到了这些知识点的实现, 接下来就通过异常测试进行验证(这些验证都是围绕本文开头扔的那张流程图展开的, 很重要, 所以, 再贴一遍)
验证消息发送到Exchange失败情况下的回调, 对应上图P -> X
如何验证? 可以随便指定一个不存在的交换机名称, 请求接口, 看是否会触发回调
发送失败, 原因: reply-code=404, reply-text=NOT_FOUND - no exchange 'mail.exchangeabcd' in vhost '/'
, 该回调能够保证消息正确发送到Exchange, 测试完成
验证消息从Exchange路由到Queue失败情况下的回调, 对应上图X -> Q
同理, 修改一下路由键为不存在的即可, 路由失败, 触发回调
发送失败, 原因: route: mail.routing.keyabcd, replyCode: 312, replyText: NO_ROUTE
验证在手动ack模式下, 消费端必须进行手动确认(ack), 否则消息会一直保存在队列中, 直到被消费, 对应上图Q -> C
将消费端代码channel.basicAck(tag, false);// 消费确认
注释掉, 查看控制台和rabbitmq管控台
可以看到, 虽然消息确实被消费了, 但是由于是手动确认模式, 而最后又没手动确认, 所以, 消息仍被rabbitmq保存, 所以, 手动ack能够保证消息一定被消费, 但一定要记得basicAck
验证消费端幂等性
接着上一步, 去掉注释, 重启服务器, 由于有一条未被ack的消息, 所以重启后监听到消息, 进行消费, 但是由于消费前会判断该消息的状态是否未被消费, 发现status=3
, 即已消费, 所以, 直接return
, 这样就保证了消费端的幂等性, 即使由于网络等原因投递成功而未触发回调, 从而多次投递, 也不会重复消费进而发生业务异常
验证消费端发生异常消息也不会丢失
很显然, 消费端代码可能发生异常, 如果不做处理, 业务没正确执行, 消息却不见了, 给我们感觉就是消息丢失了, 由于我们消费端代码做了异常捕获, 业务异常时, 会触发: channel.basicNack(tag, false, true);
, 这样会告诉rabbitmq该消息消费失败, 需要重新入队, 可以重新投递到其他正常的消费端进行消费, 从而保证消息不被丢失
测试: send方法直接返回false即可(这里跟抛出异常一个意思)
可以看到, 由于channel.basicNack(tag, false, true)
, 未被ack的消息(unacked)会重新入队并被消费, 这样就保证了消息不会走丢
验证定时任务的消息重投
实际应用场景中, 可能由于网络原因, 或者消息未被持久化MQ就宕机了, 使得投递确认的回调方法ConfirmCallback
没有被执行, 从而导致数据库该消息状态一直是投递中
的状态, 此时就需要进行消息重投, 即使也许消息已经被消费了
定时任务只是保证消息100%投递成功, 而多次投递的消费幂等性需要消费端自己保证
我们可以将回调和消费成功后更新消息状态的代码注释掉, 开启定时任务, 查看是否重投
可以看到, 消息会重投3次, 超过3次放弃, 将消息状态置为投递失败状态, 出现这种非正常情况, 就需要人工介入排查原因
不知道大家发现没有, 在MailConsumer
中, 真正的业务逻辑其实只是发送邮件mailUtil.send(mail)
而已, 但我们又不得不在调用send
方法之前校验消费幂等性, 发送后, 还要更新消息状态为"已消费"状态, 并手动ack, 实际项目中, 可能还有很多生产者-消费者的应用场景, 如记录日志, 发送短信等等, 都需要rabbitmq, 如果每次都写这些重复的公用代码, 没必要, 也难以维护, 所以, 我们可以将公共代码抽离出来, 让核心业务逻辑只关心自己的实现, 而不用做其他操作, 其实就是AOP
为达到这个目的, 有很多方法, 可以用spring aop, 可以用拦截器, 可以用静态代理, 也可以用动态代理, 在这里, 我用的是动态代理
目录结构如下:
核心代码就是代理的实现, 这里就不把所有代码贴出来了, 只是提供一个思路, 我们要尽可能地把代码写的更简洁更优雅