导航网站是怎么做的,有哪些可以做翻译兼职的网站吗,怎么做盈利的网站,茶叶网页设计素材目录 1. 为什么消息队列会丢消息#xff1f;
2. 怎么保障消息可靠传递#xff1f;
2.1 生产者不丢消息
2.2 服务端不丢消息
2.3 消费者不丢消息
3. 消息丢失如何快速止损#xff1f;
3.1 完善监控
3.2 完善止损工具 1. 为什么消息队列会丢消息#xff1f;
现在主流…目录 1. 为什么消息队列会丢消息
2. 怎么保障消息可靠传递
2.1 生产者不丢消息
2.2 服务端不丢消息
2.3 消费者不丢消息
3. 消息丢失如何快速止损
3.1 完善监控
3.2 完善止损工具 1. 为什么消息队列会丢消息
现在主流的消息队列都会提供完善的高可用解决方案但是我们依然会有多种原因导致消息丢失可能得原因包括生产者生产消息失败、服务端存储消息失败、消费者消息处理失败。
其中常见的生产者生产消息失败的原因包括
消息体过大网络传输异常配置错误例如topic配置错误生产者应用程序异常
服务端存储消息失败的常见原因包括
配置问题例如高性能方面考虑未配置主从同步、未配置持久化存储空间不足/存储介质故障
消费者消息处理失败的常见原因包括
消费者应用程序异常消费者处理超时消费过程中出现服务重启等问题
2. 怎么保障消息可靠传递
2.1 生产者不丢消息
快速重试在程序设计时需要关注异常处理机制我们需要遵循的原则是异常处理 自动重试 告警缺一不可详细展开讲就是1、任何系统异常避免在不确定情况下随意捕获异常从而导致被错误”兜底“处理。2、在生产消息异常情况下需要支持异常情况下的自动重试且多次重试需要有一定间隔时间。此方案要求消费者幂等3、遇到预期之外的异常及时埋点、告警等。消息补偿引入异常补偿服务通过异常补偿服务收集生产者、消费者的异常消息进行持久化 重试。
2.2 服务端不丢消息
MQ Cluster不丢消息关键参考消息队列高可用方案总结下来就是
持久化持久化的目的是在服务故障或宕机时消息不会丢失。对于RabbitMQ、Kafka、RocketMQ等不同的消息队列除了消息日志被持久化之外还需要关注元数据的持久化例如RabbitMQ中的Exchange元数据、Queue元数据等、偏移量的持久化等。消息备份RabbitMQ、Kafka、RocketMQ都支持消息备份但是消息备份机制上存在一些差异Kafka是针对每个分区都有主副本和多个从副本RabbitMQ是采用镜像队列的方式RocketMQ是每个消息主题都有主节点和多个从节点。ACK确认机制RabbitMQ、Kafka、RocketMQ在消息的ACK确认机制上差异不大区别在于Kafka是基于分区的消息提交机制也即某个分区所有消息消费完成后进行ACKRabbitMQ是基于消费者的消息确认机制即只有当消费者成功消费并处理了某条消息后才会进行ACK确认RocketMQ采用基于消费者组的消息确认机制即只有当某个消费者组中所有消费者都成功消费并处理了某条消息后才会进行确认。
2.3 消费者不丢消息
快速重试类似于生产者的解决方案对于消息消费的异常需要感知并进行重试。在消费者的重试上需要注意1、消息的重试次数需要有限避免无限重试影响后续的消费2、消息的消费需要幂等避免前一次消费正常再次消费时出现错误。监控消息除了正常的消费队列引入延迟的监控队列在监控队列中通过状态等属性监听消费者处理的正确性对于消费异常的情况可以发送补偿消息。
3. 消息丢失如何快速止损
3.1 完善监控
实时监控就是无论是生产者还是消费者都需要及时捕获处理异常并进行告警处理。旁路监控就是引入监控队列/定时任务的方案检查生产者与消费者的数据一致性对于生产者与消费者数据不一致的场景进行及时告警处理。趋势监控趋势监控是一种发现大规模问题的方法也即埋点记录每一秒钟/每一分钟发出去的消息数若代码变更后导致生产消息数/消费消息数明显降低则需要及时关注进行处理。
3.2 完善止损工具
消息生产工具在日常开发中建议养成在生产者发送消息前打印消息体日志的习惯。在发现数据异常后可以重新手动发送消息。数据检查/回退工具止损工具大家容易想到把消息重新生产一遍也知道消息的消费需要具有幂等性。但是生产环境通常比较复杂偶尔会产生一些异常数据导致消息生产/消费失败或者消息处理一半产生预料之外的脏数据。这里建议建设相关一些数据快速回退工具、数据正确性工具加快故障处理速度。
