RocketMQ相关知识点

Linging_24

已于 2024-04-14 09:50:49 修改

阅读量642

点赞数

分类专栏：知识点总结文章标签：面试 java rocketmq

于 2021-10-11 23:28:30 首次发布

本文链接：https://blog.csdn.net/Linging_24/article/details/120632730

版权

知识点总结专栏收录该内容

31 篇文章 0 订阅

订阅专栏

rocketmq的架构原理：https://www.cnblogs.com/qdhxhz/p/11094624.html
rocketmq的入门使用：https://blog.csdn.net/Linging_24/article/details/120659175?spm=1001.2014.3001.5501
rocketmq的面试题：https://www.cnblogs.com/javazhiyin/p/13327925.html
https://mp.weixin.qq.com/s/IvBt3tB_IWZgPjKv5WGS4A

消息队列的优缺点，以及使用场景？
如何保证消息不被重复消费？
由于网络波动的原因，无法保证生产消息和消费消息时的重复，所以只能保证消息的幂等性。
如何保证消息不丢失

broker默认是异步刷盘。
如何让RocketMQ保证消息的顺序消费？
将消息发送到同一个topic的同一个Queue中，然后消费从这个topic的queue中去拿消息消费。使用MessageListenerOrderly处理顺序消息。
1.使用串行单队列方式消费
2.rocketmq可以将消息路由到某一个队列，然后由单个消费者消费
3.消息发送时携带时间戳或版本号，消费时验证前一条消息的版本号或时间戳小于当前消息的时间戳或版本号则可以消费
如何保证消息发送到同一个queue中？
rocketmq给我们提供了一个接口MessageQueueSelector，可以实现相同规则的消息发送到同一个queue中。
RocketMQ消费模式有几种？

消费模型由Consumer决定，消费维度为Topic。

集群消费
1.一条消息只会被同Group中的一个Consumer消费
2.多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据

广播消费
消息将对一个Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。
消费消息是push还是pull？
RocketMQ没有真正意义的push，都是pull，虽然有push类，但实际底层实现采用的是长轮询机制，即拉取方式。
什么是死信队列？什么是延时队列？
1.死信队列：当消息消费失败，会进入重试队列，进行重试消费，当重试次数达到一定时，消息还是消费失败，就会进入死信队列，用于存放没有被消费的消息。
2.延时队列：用来存放需要在指定时间被处理的元素的队列，通常可以用来处理一些具有过期性操作的业务，比如十分钟未处理则取消订单。
rocketmq的事务消息原理
1. 生产者发送消息到MQ中，并标识为半消息，存储在半消息队列中，该队列对业务透明，不会被消费者消费到。
2. broker接收到消息并回调执行本地事务中的内容，本地事务执行之后会返回事务的状态（成功、回滚、未知）其中的一种。
  1. 返回成功：即本地事务执行成功，MQ将半消息队列中的消息移入真正的会被消费者消费的队列中。由消费者进行消费。
  2. 返回回滚：即本地事务执行失败，MQ会删除半消息队列中的消息。
  3. 返回未知：即本地事务执行的状态为未知，此时MQ会进行消息回查，回查的逻辑由自己实现，来判断本地事务是否执行成功。事务回查的时间间隔为1分钟，每隔1分钟进行一次回查，最大回查次数为15次，达到最大次数消息会被丢弃。
MQ的选型有哪些？及特点？
https://www.cnblogs.com/stone531/p/10519279.html
https://blog.csdn.net/weixin_43628257/article/details/123065984

性能特点：
- 吞吐量：不同消息队列在处理消息时的吞吐量可能有所不同，可以根据业务需求选择适合的消息队列。
- 延迟：消息队列的消息传递延迟也是一个重要指标，某些业务对消息传递的延迟要求较高，需要选择具有低延迟特点的消息队列。
可靠性特点：
- 消息持久化：消息队列是否支持消息持久化，以确保消息不会丢失。
- 消息传递保证：消息队列是否提供消息传递的可靠性保证，例如至少一次传递、精确一次传递等。
扩展性特点：
- 集群支持：消息队列是否支持集群部署，以实现水平扩展和高可用性。
- 分区支持：某些消息队列支持消息分区，可以将消息分散存储在不同的节点上，提高系统的扩展性。
功能特点：
- 消息模型：不同消息队列可能支持不同的消息模型，例如点对点（P2P）模型、发布订阅（Pub/Sub）模型等。
- 消息过滤：是否支持消息过滤功能，可以根据消息的属性进行过滤和选择性消费。
管理和监控特点：
- 管理工具：消息队列是否提供管理和监控工具，方便对消息队列进行配置、监控和管理。
- 监控指标：消息队列是否提供丰富的监控指标，以便进行性能调优和故障排查。
社区和生态：
- 开源社区支持：开源消息队列通常有活跃的社区支持，能够获得及时的技术支持和更新。
- 生态系统：消息队列的生态系统是否完善，是否有丰富的插件和工具支持。

rocketmq的消息重试
https://blog.csdn.net/weixin_34452850/article/details/82746852
rocketMq中消费者、消费者组、topic、queue的关系
1. 同一个消费者组下的消费者，不能同时消费同一个queue下的消息
2. 同一个消费者组下的消费者，可以同时消费同一个topic下的不同queue下的消息
3. 同一个消费者组下的消费者，不可以同时消费不同topic下的消息
4. 不同消费者组下的消费者，可以同时消费同一个topic下的相同queue下的消息
消息堆积了怎么处理？
1. 增加消费者
2. 优化消费速率
3. 控制消息投递速率
4. 消息迁移
5. 扩容mq队列
6. 监控和报警
消息丢失了如何补偿？
消息队列消息丢失的场景主要有以下几种：
1. 生产者发送消息失败：当生产者发送消息到消息队列时，如果网络故障或其他原因导致发送失败，消息可能会丢失。这可能发生在生产者与消息队列之间的网络连接中断、生产者发送消息的过程中出现异常等情况下。
2. 消息队列服务宕机：如果消息队列服务发生故障或崩溃，尚未被消费的消息可能会丢失。这种情况可能发生在消息队列服务的硬件故障、操作系统崩溃、服务进程意外终止等情况下。
3. 消息消费者处理失败：当消息队列将消息发送给消费者时，如果消费者处理消息的过程中出现异常或错误，消息可能会丢失。这可能发生在消费者处理消息的代码中出现bug、消费者处理消息的过程中发生意外终止等情况下。
4. 消息队列配置错误：如果消息队列的配置不正确，例如设置了过期时间、消息持久化等选项不正确，可能会导致消息在一定时间后被删除或丢失。
为了避免消息丢失，可以采取以下措施：
- 使用可靠的消息队列服务：选择可靠的消息队列服务提供商，确保其提供高可用性、持久化存储等功能，以减少消息丢失的风险。
- 消息持久化：将消息持久化到磁盘，确保即使在消息队列服务宕机或重启后，消息也能够得到恢复。
- 设置消息确认机制：使用消息确认机制，确保消息在被消费者成功处理后才被标记为已消费，避免消息在处理失败时被丢失。
- 监控和报警：监控消息队列的运行状态，及时发现异常情况并采取相应的措施。
- 异常处理和重试：在消费者处理消息时，捕获异常并进行适当的处理，例如重试、记录日志等，以确保消息不会因为消费者处理失败而丢失。
如果消息丢失了，可以根据具体情况采取以下几种措施：
1. 检查消息队列服务状态：首先，检查消息队列服务的状态，确保服务正常运行。如果消息队列服务出现故障或崩溃，需要尽快恢复服务。
2. 查找消息丢失原因：确定消息丢失的原因，可以检查生产者发送消息的代码、消息队列的配置、消费者处理消息的代码等。查看日志、排查代码等方式可以帮助找出消息丢失的具体原因。
3. 恢复丢失的消息：如果消息队列服务支持消息持久化，可以尝试从持久化存储中恢复丢失的消息。根据消息队列服务的文档和API，查找恢复消息的方法和工具。
4. 重新发送消息：如果无法从持久化存储中恢复丢失的消息，可以考虑重新发送消息。可以在生产者端实现重试机制，当发现消息发送失败或丢失时，重新发送消息。
5. 数据补偿：如果消息丢失对业务造成了影响，需要根据业务需求进行数据补偿。可以通过其他方式重新生成或恢复丢失的数据，确保业务的完整性和一致性。
6. 加强监控和预防措施：为了避免消息丢失，可以加强监控和预防措施。监控消息队列的运行状态，及时发现异常情况并采取相应的措施。同时，对消息队列的配置、消息发送和处理的代码进行审查和测试，确保其正确性和可靠性。
在消息丢失的情况下，及时发现问题、分析原因，并采取相应的措施是非常重要的。根据具体的业务需求和系统环境，选择合适的方法来处理消息丢失问题。