面试连环炮系列(二十️五):RocketMQ怎么保证消息不丢失
- RocketMQ怎么保证消息不丢失?
-
A. 从Producer的视角来看:如果消息未能正确的存储在MQ中,或者消费者未能正确的消费到这条消息,都是消息丢失。
-
B. 从Broker的视角来看:如果消息已经存在Broker里面了,如何保证不会丢失呢(宕机、磁盘崩溃)。
-
C. 从Consumer的视角来看:如果消息已经完成持久化了,但是Consumer取了,但是未消费成功且没有反馈,就是消息丢失。
-
D. 从Producer分析:如何确保消息正确的发送到了Broker?
默认情况下,可以通过同步的方式阻塞式的发送,checkSendStatus,状态是OK,表示消息一定成功的投递到了Broker,状态超时或者失败,则会触发默认的2次重试。此方法的发送结果,可能Broker存储成功了,也可能没成功。
采取事务消息的投递方式,并不能保证消息100%投递成功到了Broker,但是如果消息发送Ack失败的话,此消息会存储在CommitLog当中,但是对ConsumerQueue是不可见的。可以在日志中查看到这条异常的消息,严格意义上来讲,也并没有完全丢失。
RocketMQ支持日志的索引,如果一条消息发送之后超时,也可以通过查询日志的API,来check是否在Broker存储成功。
从Broker分析:如果确保接收到的消息不会丢失?
消息支持持久化到Commitlog里面,即使宕机后重启,未消费的消息也是可以加载出来的Broker自身支持同步刷盘、异步刷盘的策略,可以保证接收到的消息一定存储在本地的内存中。Broker集群支持1主N从的策略,支持同步复制和异步复制的方式,同步复制可以保证即使Master磁盘崩溃,消息仍然不会丢失。
从Cunmser分析:如何确保拉取到的消息被成功消费?
消费者可以根据自身的策略批量Pull消息,Consumer自身维护一个持久化的offset(对应MessageQueue里面的min offset),标记已经成功消费或者已经成功发回到broker的消息下标。如果Consumer消费失败,那么它会把这个消息发回给Broker,发回成功后,再更新自己的offset。如果Consumer消费失败,发回给broker时,broker挂掉了,那么Consumer会定时重试这个操作。
如果Consumer和broker一起挂了,消息也不会丢失,因为consumer里面的offset是定时持久化的,重启之后,继续拉取offset之前的消息到本地。
- RocketMQ如何保证消息不重复?
绝大多数情况下,消息是不重复的。在网络抖动、应用处理超时等异常情况下,无法保证消息不重复,但是能保证消息不丢失。消息重复分两种情况:
- 发送时消息重复
当一条消息已被成功发送到服务端并完成持久化,此时出现了网络闪断或者客户端宕机,导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息,消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
- 投递时消息重复
消息消费的场景下,消息已投递到消费者并完成业务处理,当客户端给服务端反馈应答的时候网络闪断。为了保证消息至少被消费一次,消息队列 RocketMQ的服务端将在网络恢复后再次尝试投递之前已被处理过的消息,消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
正常情况下出现重复消息的概率小,如果RocketMQ实现判重的话,肯定会降低吞吐量和高可用,最好由业务端自己处理重复消息。
- 消费端收到两条一样的消息,应该怎样处理
消费端按业务唯一标识保持业务处理幂等性。只要保持幂等性,不管来多少条重复消息,最后处理的结果都一样。
- RocketMQ可以是实现顺序消息吗?
顺序消息是指哪条消息先进入,哪条消息就会先被消费,符合FIFO。RocketMQ支持顺序消息,又分为分区顺序和全局顺序。全局顺序其实是分区顺序的一个特例,即使Topic只有一个分区。全局顺序将面临性能的问题,而且绝大多数场景都不需要全局顺序。
在MQ的模型中,顺序需要由3个阶段去保障:
-
消息被发送时保持顺序
用户在同一个线程中采用同步的方式发送消息。 -
消息被存储时保持和发送的顺序一致
Producer端确保消息顺序唯一要做的事情就是将消息路由到特定的分区,在RocketMQ中,通过MessageQueueSelector来实现分区的选择。public interface MessageQueueSelector { MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg); }
-
List
mqs:消息要发送的Topic下所有的分区 -
Message msg:消息对象
-
额外的参数:用户可以传递自己的参数
如下实现就可以保证相同的订单的消息被路由到相同的分区:
long orderId = ((Order) object).getOrderId;
return mqs.get(orderId % mqs.size());
- 消息被消费时保持和存储的顺序一致
RocketMQ消费端有两种类型:MQPullConsumer和MQPushConsumer。
MQPullConsumer由用户控制线程,主动从服务端获取消息,每次获取到的是一个MessageQueue中的消息。PullResult中的List msgFoundList自然和存储顺序一致,用户需要再拿到这批消息后自己保证消费的顺序。
- 使用顺序消息存在哪些问题?
需要有顺序关系的消息发送到同一个queue中,而不是使用客户端自带的负载均衡策略,所以一旦量比较大,可能会造成这个队列消息量很大,而其它队列比较空闲的情况。
顺序消息处理也必须在同一个consumer上,而且同一个queue的消息只能单线程处理,也存在消息堆积的可能。
如果业务处理消息失败,只会在consumer端重试,到达重试次数之后。会直接放入broker中的死信队列。
- 顺序消息无法保证100%消息的顺序。例如,有消息m1,m2,m3需要顺序处理,m1被发到q1中,这时候q1所在的broker宕机,Producer会另外选择一个queue来投递m2和m3,这个时候m1和m2会到达不同的consumer上。当然这种情况发生的概率是非常低的,因为producer从检测到broker宕机到切换queue需要一段时间,同时consumer要有消息堆积才会造成这种现象的出现。
参考(摘抄的文字版权属于原作者):
https://blog.csdn.net/leeasony/article/details/104857576
https://blog.csdn.net/qq_38545713/article/details/104758104
https://www.jianshu.com/p/e1831c883e54
https://www.cnblogs.com/hzmark/p/orderly_message.html
本文链接:https://www.codingbrick.com/archives/515.html
特别声明:除特别标注,本站文章均为原创,转载请注明作者和出处倾城架构,请勿用于任何商业用途。