消息队列必知必会-RocketMQ

---

1. 什么是rocketmq？

• RocketMQ 是阿里巴巴在 2012 年开源的分布式消息中间件
• RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理， binglog 分发等场景。

2. RocketMQ 由哪些角色组成？

• 生产者（Producer）：负责产生消息，生产者向消息服务器发送由业务应用程序系统生成的消息。
• 消费者（Consumer）：负责消费消息，消费者从消息服务器拉取信息并将其输入用户应用程序。
• 消息服务器（Broker）：是消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。
• 名称服务器（NameServer）：用来保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找 Broker 信息。

3. RocketMQ 的整体流程？

• Nameserver启动后监听端口，等待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心。
• Broker启动，跟所有的 Namesrv 保持长连接，定时发送心跳包（包含当前 Broker 信息(IP+端口等)以及存储所有 Topic 信息。注册成功后，Nameserver集群中就有Topic跟Broker的映射关系）收发消息前，先创建Topic 。创建 Topic时，需要指定该Topic要存储在哪些Broker上。也可以在发送消息时自动创建Topic
• Producer 发送消息。启动时，先跟 Namesrv 集群中的其中一台建立长连接，并从Namesrv 中获取当前发送的 Topic 存在哪些 Broker 上，然后跟对应的 Broker 建立长连接，直接向 Broker 发消息。
• Consumer 消费消息。跟其中一台 Namesrv 建立长连接，获取当前订阅 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立连接通道，开始消费消息。

4. Producer 发送消息有几种方式？

• 同步方式
• 异步方式
• Oneway 方式 适合大数据场景，允许有一定消息丢失的场景。如日志

5. 消费者消费模式有几种？

• 集群消费：一个 Consumer Group 中的各个 Consumer 实例分摊去消费消息，即一条消息只会被 Consumer Group 中的一个Consumer消费一次。
• 广播消费：一 个Consumer Group 下的各个 Consumer 实例都投递一遍。即一条消息消息会被 Consumer Group 中的每个Consumer消费一次。

6. 消费者获取消息有几种模式？

• PushConsumer推送模式:（虽然 RocketMQ 使用的是长轮询）的消费者。消息的能及时被消费。使用非常简单，内部已处理如线程池消费、流控、负载均衡、异常处理等等的各种场景。
• PullConsumer拉取模式的消费者。应用主动控制拉取的时机，怎么拉取，怎么消费等。主动权更高。但要自己处理各种场景。

7. 如何对消息进行重放？

• 消费位点就是一个数字，把 Consumer Offset 改一下，就可以达到重放的目的了。

8. 顺序消息

• 生产者必须单一生产者串行发送,使用 MessageQueueSelector 为某一批消息（通常是有相同的唯一标示id）选择同一个 Queue ，则这一批消息的消费将是顺序消息（并由同一个consumer完成消费）。
• 消费者类型必须为PushConsumer消息消费的顺序性需要由业务方自行保证。
• 普通顺序消息:正常情况下可以保证完全的顺序消息，但是一旦发生异常，Broker 宕机或重启，由于队列总数发生发化，消费者会触发负载均衡，而默认地负载均衡算法采取哈希取模平均，这样负载均衡分配到定位的队列会发化，使得队列可能分配到别的实例上，则会短暂地出现消息顺序不一致。如果业务能容忍在集群异常情况（如某个 Broker 宕机或者重启）下，消息短暂的乱序，使用普通顺序方式比较合适。
• 严格顺序消息：无论正常异常情况都能保证顺序，牺牲了分布式 Failover 特性，即 Broker 集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主避免，不过仍然会存在几分钟的服务不可用。（依赖同步双写，主备自动切换，自动切换功能目前并未实现）

9. 如何防止消息丢失？可靠性传输？

• 生产者将消息发送给Rocket MQ的时候，如果出现了网络抖动或者通信异常等问题，消息就有可能会丢失。（rocketmq事务，先发送half消息，然后rocketmq返回ack，执行本地事务，成功则发送commit，失败rollback，如果commit或者rollback消息处理会有消息状态回查）

• RocketMQ为了减少磁盘的IO，会先将消息写入到os cache中，而不是直接写入到磁盘中，隔一段时间后异步持久化到磁盘，在os cache中消息就有可能会丢失（rocketmq集群，异步刷盘策略改为同步刷盘，异步复制改为同步复制）

• 消费者成功从RocketMQ中获取到了消息，还没有将消息完全消费完的时候，就通知RocketMQ我已经将消息消费了，然后消费者宕机，但是RocketMQ认为消费者已经成功消费了数据，所以数据依旧丢失了。
  当你的消息处理完毕之后，才会返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS 只有返回了CONSUME_SUCCESS，消费者才会告诉RocketMQ我已经消费完了，此时如果消费者宕机，消息已经处理完了，也就不会丢失消息了

• RocketMQ 采用文件系统的方式来存储消息，消息的主要存储文件包括 CommitLog 文件、ConsumeQueue 文件、IndexFile 文件。

• Producer 将消息发送到 Broker 后，Broker 会采用同步或者异步的方式把消息写入到 CommitLog。RocketMQ 所有的消息都会存放在 CommitLog 中。对 CommitLog 写之前会加锁。只要消息被持久化到磁盘文件 CommitLog，那么就可以保证 Producer 发送的消息不会丢失。commitLog是顺序写的

• CommitLog 持久化后，会把里面的消息 Dispatch 到对应的 Consume Queue 上，是一个逻辑队列，存储了这个 Queue 在 CommitLog 中的起始 Offset，log 大小和 MessageTag 的 hashCode。

• 当消费者进行消息消费时，会先读取 ConsumerQueue，逻辑消费队列 ConsumeQueue 保存了指定 Topic 下的队列消息在 CommitLog 中的起始物理偏移量 Offset，消息大小、和消息 Tag 的 HashCode 值

• 直接从 ConsumerQueue 中读取消息是没有数据的，真正的消息主体在 CommitLog 中，所以还需要从 CommitLog 中读取消息。

• 消费用的观察者模式

10. 高可用

• 多节点（集群）多副本模式-异步复制
• 多节点（集群）多副本模式-同步复制

---

总结

本文介绍了的使用，如有问题欢迎私信和评论