rabbitMQ如何保证数据不丢失

1.生产消息保证消息不丢失

Q: 当订单服务发送一条消息到rabbitMQ, rabbitMQ成功接收到了消息并保存在内存中, 但是在仓储服务没有拿走此消息之前, rabbitMQ宕机了. 怎么办?

A:此问题需要考虑消息持久化(durable机制), 通过设置队列的durable参数为true, 则当rabbitMQ重启之后, 会恢复之前的队列. 它的工作原理是rabbitMQ会把队列的相关信息持久化到磁盘。

2.消费消息保证消息不丢失

2.1 消费者服务宕机

Q: 仓储服务在接收到一条订单消息之后, 并对此条消息没有处理完之前,突然宕机了. 换句话说, 仓储服务在接收到订单消息之后, 仓储服务调用发货系统之前, 仓储服务宕机了. 这个时候应该怎么办?

A: rabbitMQ默认操作是当消费者成功接收到消息之后,rabbitMQ则会自动的在队列中将此条消息删除. 这种操作称为自动ACK(自动回复)。autoAck这个参数. 需要将此参数设置为false. 当此参数设置为false. 那么当消费者接收到这个消息之后,消息队列也不会马上删除这条消息. 对于我们开发人员要做的就是只有仓储服务执行完毕并调用成功发货之后才会向消息对返回一条确认消息,当消息队列接收到这条消息之后才删除订单消息

Q: rabbitMQ是如何感知到消费者宕机的?

A: 消费者实例已经注册到了rabbitMQ, 所以rabbitMQ与消费者实例是存在联系的,当消费者实例宕机,rabbitMQ必然会知道

Q:基于ack机制,结合高并发场景会出现什么问题?

A: 对于当前的操作, 每一个channel都会存在若干的unack消息(未确认消息). 比方说, rabbitMQ正在发送的消息 、 消费者实例接收到消息之后但没有处理完 、 执行了ack但是因为ack是异步的也不会马上变为ack信息 、 开始批量ack延迟时间会更长.对于这些场景,都会存在unack的消息. 此时如果rabbitMQ无限制的过多过快的向消费者实例发送消息,就会导致庞大的unack消息积压在消费者实例的内存中,如果继续保持发与积压的状态,最终会导致消费者实例的oom!

rabbitMQ基于 prefetch count(预抓取总数)控制每一个channel的unack消息的数量。结合高并发场景考虑prefetch count的值设置多大合适。过大: 在高并发场景下, 可能每秒都会几千上万条消息. 如果仍旧把prefetch count 设置过大超出了消费者实例内存的处理能力, 消费者实例可能瞬间就崩溃；过小: 如果设置过小,会导致系统的消息吞吐量降低,影响系统性能. 因为执行ack方法是异步的 . 举例. 将prefetch count 设置为1. 则rabbitMQ最终投递给消费者实例一条unack消息. 当消费者实例消费者这条信息,并执行了ack方法, 因为该方法需要异步执行.官网给出的建议是设置在100~300之间. 但是在实际生产环境下, 具体环境需要具体确定.