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.遇到消息失败的消息,无法跳过,当前队列消费暂停