RocketMQ_高级特性之消息查询_2-【官方】百战程序员_IT在线教育培训机构

按MessageId查询消息
RocketMQ中的MessageId的长度总共有16字节，其中包含了消息存储主机地址（IP地址和端口），消息Commit Log offset。“按照MessageId查询消息”在RocketMQ中具体做法是：Client端从MessageId中解析出Broker的地址（IP地址和端口）和Commit Log的偏移地址后封装成一个RPC请求后通过Remoting通信层发送（业务请求码：VIEW_MESSAGE_BY_ID）。Broker端走的是QueryMessageProcessor，读取消息的过程用其中的 commitLog offset 和 size 去 commitLog 中找到真正的记录并解析成一个完整的消息返回。
按照Message Key查询消息
按照Message Key查询消息”，主要是基于RocketMQ的IndexFile索引文件来实现的。RocketMQ的索引文件逻辑结构，类似JDK中HashMap的实现。索引文件的具体结构如下：

rocketmq_design_13

IndexFile索引文件为用户提供通过“按照Message Key查询消息”的消息索引查询服务，IndexFile文件的存储位置是：$HOME\store\index${fileName}，文件名fileName是以创建时的时间戳命名的，文件大小是固定的，等于40+500W4+2000W20= 420000040个字节大小。如果消息的properties中设置了UNIQ_KEY这个属性，就用 topic + “#” + UNIQ_KEY的value作为 key 来做写入操作。如果消息设置了KEYS属性（多个KEY以空格分隔），也会用 topic + “#” + KEY 来做索引。

其中的索引数据包含了Key Hash/CommitLog Offset/Timestamp/NextIndex offset 这四个字段，一共20 Byte。NextIndex offset 即前面读出来的 slotValue，如果有 hash冲突，就可以用这个字段将所有冲突的索引用链表的方式串起来了。Timestamp记录的是消息storeTimestamp之间的差，并不是一个绝对的时间。整个Index File的结构如图，40 Byte 的Header用于保存一些总的统计信息，4500W的 Slot Table并不保存真正的索引数据，而是保存每个槽位对应的单向链表的头。202000W 是真正的索引数据，即一个 Index File 可以保存 2000W个索引。

“按照Message Key查询消息”的方式，RocketMQ的具体做法是，主要通过Broker端的QueryMessageProcessor业务处理器来查询，读取消息的过程就是用topic和key找到IndexFile索引文件中的一条记录，根据其中的commitLog offset从CommitLog文件中读取消息的实体内容。

由于消息在消息队列RocketMQ中存储的时间默认为3天（不建议修改），即只能查询从当前查询时间算起3天内的消息，三种查询方式的特点和对比如下表所述：

查询方式	查询条件	查询类别	说明
按Message ID查询	Topic+Message ID	精确查询	根据Topic和Message ID可以精确定位任意一条消息，获取消息的属性。
按Message Key查询	Topic+Message Key	模糊查询	根据Topic和Message Key可以匹配到包含指定Key的最近64条消息。注意建议消息生产方为每条消息设置尽可能唯一的Key，以确保相同的Key的消息不会超过64条，否则消息会漏查。
按Topic查询	Topic+时间段	范围查询	根据Topic和时间范围，批量获取符合条件的所有消息，查询量大，不易匹配。

查询流程如下图：

查询流程

实时效果反馈

1.消息查询的方式有哪些？

A 按messageID查询

B 按messageKey查询

C 按消息轨迹查询

D 以上都是

答案

1=>D

RocketMQ_高级特性之消息查询_1 RocketMQ_应用实战_发送单向消息

北京市昌平区回龙观镇南店村综合商业楼2楼226室