RocketMQ简介

RocketMQ 是什么？

是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
 Producer、Consumer、队列都可以分布式。
 Producer 向一些队列轮流发送消息，队列集合称为 Topic，Consumer 如果做广播消费，则一个 consumer 实例消费这个Topic 对应的所有队列，如果做集群消费，则多个 Consumer 实例平均消费这个 topic 对应的队列集合。
 能够保证严格的消息顺序
 提供丰富的消息拉取模式
 亿级消息堆积能力

物理部署：


 Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
 Broker 部署相对复杂，Broker 分为 Master 和 Slave，一个 Master 可以对应多个 Slave，但是一个 Slave 只能对应一个 Master。
 BrokerId为 o 表示 Master，非 o 表示 Slave。Master 也可以部署多个。每个 Broker 和 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server。
 Producer 和 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 获取 Topic 路由信息，并向提供 Topic 服务Master 建立长连接，定时向 Master 发送心跳。Producer 完全无状态，可集群部署。
 Consumer 不 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的Master、Slave 建立长连接，丏定时吐 Master、Slave 収送心跳。Consumer既可以从 Master 订阅消息，也可以从 Slave 订阅消息，订阅规则由 Broker 配置决定。

消息存储：

（1）消息主体以及元数据都存储在CommitLog当中
（2）Consume Queue是一个逻辑队列，存储了这个Queue在CommiLog中的 起始offset，log大小和MessageTag的hashCode。
（3）每次读取消息队列先读取consumer Queue,然后再通过consumerQueue去commitLog中拿到消息主体。

刷盘：
RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存不磁盘都有一份数据，访问时，直接从内存读取。
异步刷盘方式：

同步刷盘方式：

同步刷盘和异步刷盘的唯一区别是：异步刷盘写完 PAGECACHE 直接返回，而同步刷盘需要等待刷盘完成才返回

消息查询：
按照 Message Id 查询消息：

MsgId 总共 16 字节，包含消息存储主机地址，消息 Commit Log offset。从 MsgId 中解析出 Broker 的地址和 Commit Log 的偏移地址，然后按照存储格式所在位置消息 buffer 解析成一个完整的消息。
按照 Message Key 查询消息：
1. 根据查询的 key 的 hashcode%slotNum 得到具体的槽在Consume Queue的位置（slotNum 是的最大槽Consume Queue的数目）。
2. 根据 slotValue（slot 位置对应的值）查找到索引项列表的最后一项（倒序排列）
3. 遍历索引项列表迒回查询时间范围内的结果集（默认一次最大返回的 32 条记录）
4. Hash 冲突；寻找 key 的 slot 位置时相当亍执行了两次散列函数，一次 key 的 hash，一次 key 的 hash 值取模，因此返里存在两次冲突的情况：
第一种，key 的 hash 值不同但模数相同，此时查询的时候会再比较一次 key 的hash 值（每个索引项保存了 key 的 hash 值），过滤掉 hash 值不相等的项。
第二种，hash 值相等但 key 不等，出于性能的考虑冲突的检测放到客户端处理，客户端比较一次消息体的 key 是否相同。

消息过滤：
(1). 在 Broker 端进行 Message Tag 比对，再遍历 Consume Queue，如果存储的 Message Tag 不订阅的 Message Tag 不符合，则跳过，继续比对下一个，符合则传输给 Consumer。注意：Message Tag 是字符串形式，Consume Queue 中存储的是其对应的 hashcode，比对时也是比对 hashcode。
(2). Consumer 收到过滤后的消息后，同样也要执行在 Broker 端的操作，但是比对的是真实的 Message Tag 字符串，而不是 Hashcode。

长轮询 Pull：
RocketMQ 的 Consumer 都是从 Broker 拉消息来消费，但是为了能做到实时收消息，RocketMQ 使用长轮询方式，可以保证消息实时性同 Push 方式一致。返回长轮询方式类似于 Web QQ 接收消息机制。

顺序消息：

顺序消息缺陷：
1.消费顺序消息的幵行度依赖亍队列数量
2.个别队列由亍哈希丌均导致消息过多，消费速度跟丌上，产生消息堆积问题
3.遇到消息失败的消息，无法跳过，当前队列消费暂停