RocketMQ

RocketMQ 是一款高性能，高吞吐量，低延迟，高可用，高可靠的分布式消息中间件

RocketMQ架构

RocketMQ角色

• Producer，消息发送者

• Consumer，消息接受者

  1. 消费者与 Broker Master ,Slave都建立连接
  2. 与NameServer 建立长连接

• Broker,暂存和传输消息

  1. Broker对应一台服务器
  2. 指定相同的BrokerName表示集群 BrokerId 0表示master，非0表示slave
  3. 每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有 NameServer。

• NameServer，管理Broker,无状态

  1. producer 与NameServer 保持长连接，定期从 NameServer获取 Topic路由信息,向Broker master写
  2. Consumer 与NameServer 保持长连接,定期从 NameServer获取 Topic路由信息. Consumer与Broker 保持长连接，从Broker master,slave1消费消息
  3. NameServer不去连接别的机器，不主动推送消息
  4. 单个Broker与所有NameServer 进行定时注册

• Topic，区分消息的种类

• Message Queue，Topic的分区,并行发送和接收消息

RocketMQ特性

1. 订阅与发布，
   1. 消息的订阅是指某个消费者关注了某个topic中，带有某些tag的消息。
2. 消息顺序
3. 消息过滤，Broker端根据tag过滤
4. 消息可靠性
5. 至少异常，每个消息必须投递一次
6. 回溯消费，时间维度回退消费进度
7. 事务消息，应用事务和发送消息定义到全局事务中
8. 定时消息，
9. 消费重试
10. 消息重投，可能会造成消息重复
11. 流量控制
12. 死信队列

消费模式

Push和Pull模式本质都是采用消费端主动拉取的方式，即consumer轮询从 broker拉取消息。

• pull模式
  • Push方式里，consumer把长轮询的动作封装了，并注册MessageListener监听器，取到消息后， 唤醒MessageListener的consumeMessage()来消费
  • 优点实时性高，缺点消费者处理能力有限，造成消息堆积
• push模式
  • 优点主动权掌握在消费端自己手中，根据自己的处理能力量力而行；缺点就是如何控制Pull的 频率。

安装

mqnamesrv
mqbroker -n localhost:9876

高级特性

提高Consumer的处理能力

1. 提高消费并行度，增加Consumer实例
2. 以批量方式进行消费，设置Consumer的 consumeMessageBatchMaxSize这个参数
3. 检测延时情况，跳过非重要消息

消息存储

顺序写可以达到 600MB/s,RocketMQ采用顺序写入

• CommitLog：消息主题及元数据的存储主体
• ConsumeQueue: 逻辑消费队列，提高消息消费的性能。ConsumeQueue 作为消费消息的索引
  • 8个字节的 CommitLog物理偏移量
  • 4字节的消息长度
  • 8字节 tag hashCode
• IndexFile: 根据key或时间区间查询消息，底层文件系统实现了 HashMap结构

同步复制和异步复制

• 同步复制
  同步复制方式是等Master和Slave均写 成功后才反馈给客户端写成功状态；在同步复制方式下，如果Master出故障，Slave上有全部的备份数据，容易恢复，但是同步复制会 增大数据写入延迟，降低系统吞吐量。

• 异步复制
  异步复制方式是只要Master写成功 即可反馈给客户端写成功状态。在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因 为没有被写 入Slave，有可能会丢失；

消息重试

• 顺序消息 消费失败，消费队列会每秒重试一次，应用出现消息消费阻塞
• 无序消息 消费失败，设置 ConsumeConcurrentlyStatus.RECONSUME_LATER 返回状态达到重试效果，只对集群消费生效，广播方式无效。

死信队列

RocketMQ中消息重试超过一定次数后（默认16次）就会被放到死信队列中

1. 一个死信队列对应一个 Group ID， 而不是对应单个消费者实例。
2. 一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。

顺序消息

部分有序

1. 发送要把同一业务ID的消息发送 到同一个Message Queue
2. 消费过程中，要做到消费者从同一个Message Queue 消费消息。消费端通过使用MessageListenerOrderly

事务消息

2阶段提交

1. 一阶段事务消息对用户不可见对消息的Topic和Queue等属性进行替换， 同时将原来的Topic和Queue信息存储到Half消息的属性中，
2. Commit和Rollback操作以及Op消息的引入，Op消息标识 事务消息已经确定的状态（Commit或者Rollback）
3. Op消息的存储和对应关系，Op消息的内容为对应的Half消息的存储的Offse
4. Half消息的索引构建，二阶段构建索引时需要读取出Half消息，并将Topic和Queue替换成真正的目标的 Topic和Queue

NameServer作用

1. NameServer 用来保存活跃的 broker 列表，包括 Master 和 Slave 。
2. NameServer 用来保存所有 topic 和该 topic 所有队列的列表。
3. NameServer 用来保存所有 broker 的 Filter 列表。
4. 命名服务器为客户端，包括生产者，消费者和命令行客户端提供最新的路由信息。