消息队列常见问题（1）-如何保障不丢消息

morning_judger

已于 2023-08-07 00:29:43 修改

阅读量501

点赞数

分类专栏：消息队列文章标签：中间件

于 2023-08-07 00:28:29 首次发布

本文链接：https://blog.csdn.net/LHW0621/article/details/132015199

版权

5 篇文章 0 订阅

订阅专栏

1. 为什么消息队列会丢消息？

现在主流的消息队列都会提供完善的高可用解决方案，但是我们依然会有多种原因导致消息丢失，可能得原因包括：生产者生产消息失败、服务端存储消息失败、消费者消息处理失败。

其中常见的生产者生产消息失败的原因包括：

服务端存储消息失败的常见原因包括：

消费者消息处理失败的常见原因包括：

快速重试：在程序设计时，需要关注异常处理机制，我们需要遵循的原则是：异常处理 + 自动重试 + 告警（缺一不可），详细展开讲就是：1、任何系统异常，避免在不确定情况下随意捕获异常，从而导致被错误”兜底“处理。2、在生产消息异常情况下，需要支持异常情况下的自动重试，且多次重试需要有一定间隔时间。（此方案要求消费者幂等）3、遇到预期之外的异常及时埋点、告警等。
消息补偿：引入"异常补偿服务"，通过异常补偿服务收集生产者、消费者的异常消息进行持久化 + 重试。

MQ Cluster不丢消息关键参考消息队列高可用方案，总结下来就是：

持久化：持久化的目的是在服务故障或宕机时，消息不会丢失。对于RabbitMQ、Kafka、RocketMQ等不同的消息队列，除了消息日志被持久化之外，还需要关注元数据的持久化（例如：RabbitMQ中的Exchange元数据、Queue元数据等）、偏移量的持久化等。
消息备份：RabbitMQ、Kafka、RocketMQ都支持消息备份，但是消息备份机制上存在一些差异，Kafka是针对每个分区都有主副本和多个从副本，RabbitMQ是采用镜像队列的方式，RocketMQ是每个消息主题都有主节点和多个从节点。
ACK确认机制：RabbitMQ、Kafka、RocketMQ在消息的ACK确认机制上差异不大，区别在于Kafka是基于分区的消息提交机制，也即某个分区所有消息消费完成后进行ACK；RabbitMQ是基于消费者的消息确认机制，即只有当消费者成功消费并处理了某条消息后，才会进行ACK确认；RocketMQ采用基于消费者组的消息确认机制，即只有当某个消费者组中所有消费者都成功消费并处理了某条消息后，才会进行确认。

快速重试：类似于生产者的解决方案，对于消息消费的异常需要感知并进行重试。在消费者的重试上需要注意：1、消息的重试次数需要有限，避免无限重试影响后续的消费；2、消息的消费需要幂等，避免前一次消费正常，再次消费时出现错误。
监控消息：除了正常的消费队列，引入延迟的监控队列，在监控队列中通过状态等属性，监听消费者处理的正确性，对于消费异常的情况可以发送补偿消息。

实时监控：就是无论是生产者，还是消费者都需要及时捕获处理异常，并进行告警处理。
旁路监控：就是引入监控队列/定时任务的方案，检查生产者与消费者的数据一致性，对于生产者与消费者数据不一致的场景进行及时告警处理。
趋势监控：趋势监控是一种发现大规模问题的方法，也即埋点记录每一秒钟/每一分钟发出去的消息数，若代码变更后导致生产消息数/消费消息数明显降低，则需要及时关注进行处理。

消息生产工具：在日常开发中，建议养成在生产者发送消息前打印消息体日志的习惯。在发现数据异常后，可以重新手动发送消息。
数据检查/回退工具：止损工具大家容易想到把消息重新生产一遍，也知道消息的消费需要具有幂等性。但是生产环境通常比较复杂，偶尔会产生一些异常数据导致消息生产/消费失败，或者消息处理一半产生预料之外的脏数据。这里建议建设相关一些数据快速回退工具、数据正确性工具，加快故障处理速度。