本文共 1822 字,大约阅读时间需要 6 分钟。
成为优秀的架构师通常是初级到中级工程师的阶段性目标。优秀的架构师往往具备七种核心能力:编程能力、调试能力、编译部署能力、性能优化能力、业务架构能力、在线运维能力、项目管理能力和规划能力。这些能力之间存在密切关联,其中编程能力、调试能力和编译部署能力是基础能力,而性能优化能力和业务架构能力则是关键能力。
在使用 RabbitMQ 的时候,作为消息发送方希望杜绝任何消息丢失或者投递失败场景。RabbitMQ 为我们提供了两种方式来控制消息的投递可靠性模式:confirm 确认模式和 return 退回模式。
当消息从 producer 发送到 exchange 时,会执行 confirmCallback 中的 confirm 方法。该方法返回包含以下信息的结果:交换机是否成功接收到消息(true 成功,false 失败),以及失败原因。
当消息发送给 exchange 后,exchange 将消息路由到 queue 失败时,会执行 returnCallback。返回的信息包括:消息对象、错误码、错误信息、交换机名称和路由键。
ack 是 Acknowledge 的缩写,表示消费端收到消息后的确认方式。RabbitMQ 提供三种确认方式:
自动确认:设置 acknowledge 为 "none"。消息一旦被 consumer 接收到,就会自动确认收到,并将相应的 message 从 RabbitMQ 的消息缓存中移除。
手动确认:设置 acknowledge 为 "manual"。如果出现异常,调用 channel.basicNack() 方法,让 RabbitMQ 自动重新发送消息。
根据异常情况确认:设置 acknowledge 为 "auto"。当消息处理过程中遇到异常时,会自动调用基本Nack 方法,重新发送消息。
TTL 是 Time To Live 的缩写,表示消息的存活时间。RabbitMQ 允许对消息和队列设置过期时间。消息过期后,会被自动清除。可以单独设置消息的 TTL,也可以设置整个队列的 TTL。消息过期可以让队列统一过期,也可以让单个消息过期。
死信队列,英文缩写为 DLX。Dead Letter Exchange(死信交换机)是指当消息成为 dead message 后,会被重新发送到另一个交换机(DLX)。死信队列的触发条件包括:
死信队列和死信交换机与普通的队列和交换机没有任何区别。要实现队列与死信交换机的绑定,只需在队列配置中设置以下参数:
延迟队列是一个强大的功能,但 RabbitMQ 本身并不提供延迟队列功能。可以通过将 TTL 和 DLX 组合使用来实现类似延迟队列的效果。例如,将消息设置为 TTL 后,如果消息未被消费,将其转发到 DLX 进行处理。
在系统峰值较高时,可以通过削峰填谷的方式使用 RabbitMQ 实现流量调节,使系统处理请求更加平稳。
尽管通过 confirm、ACK 以及死信队列等机制已经能够保证消息的高可用性和不丢失,但在复杂的生产环境中仍需额外考虑消息补偿机制。消息补偿机制需要建立在业务数据库和 MQ 数据库的基础之上。具体实现方式包括:
这种机制可以确保在极端情况下也能保证消息的可靠性。
本文仅展示部分内容,完整题库可在 我的博客 查看,包括Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件 MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等内容,持续更新中。