本文探讨了RabbitMQ中确保消息从服务器到消费者不丢失的策略，包括消费者手动ACK和镜像集群的使用。通过手动ACK，消费者在业务执行完成后通知服务器消息已处理，防止消息丢失。而镜像集群则提供了消息存储的高可用性，但可能降低系统吞吐量。文章总结了保证消息中间件高可用性的关键点，并预告了后续将讨论的消息重复消费、顺序性保障及接口重试等话题。
继续上篇文章解决RabbitMQ消息丢失问题和保证消息可靠性（一） 未完成部分，我们聊聊MQ Server端的高可用和消费端如何保证消息不丢的问题？
回归上篇的内容，我们知道消息从生产端到服务端，为了保证消息不丢，我们必须做哪些事情？
- 发送端采用Confirm模式，注意Server端没成功通知发送端，需要重发操作需要额外处理
- 消息的持久化处理
上面两个操作保证消息到服务端不丢，但是非高可用状态，如果节点挂掉，服务暂时不可用，需要重启后，消息恢复，消息不会丢失，因为有磁盘存储。
本文先从消费端讲起：
RabbitMQ Server到消费者消息如何不丢？
上面一篇文章也提到了，消费者获取到消息之后，没有来得及处理完毕，自己直接宕机了,因为消息者默认采用自动ack，此时RabbitMQ的自动ack机制会通知MQ Server这条消息已经处理好了，此时消息就丢了，并不是预期的。
那么我们采用手动ack机制来解决这个问题，消费端处理完逻辑之后再通知MQ Server，这样消费者没处理完消息不会发送ack,如果在消费者拿到消息，没来得及处理的情况下自己挂了，此时MQ集群会自动感知到，它就会自觉的
最低0.47元/天 解锁文章
扫一扫
3615
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
