终于弄明白了RocketMQ的存储模型

　　RocketMQ优异的性能表现，必然绕不开其优秀的存储模型。
　　这篇文章，笔者按照自己的理解，尝试分析RocketMQ的存储模型，希望对大家有所启发。
　　1整体概览
　　首先温习下RocketMQ架构。
　　整体架构中包含四种角色：Producer：消息发布的角色，Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。Consumer：消息消费的角色，支持以push推，pull拉两种模式对消息进行消费。NameServer：名字服务是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。BrokerServer：Broker主要负责消息的存储、投递和查询以及服务高可用保证。
　　本文的重点在于分析BrokerServer的消息存储模型。我们先进入broker的文件存储目录。
　　消息存储和下面三个文件关系非常紧密：数据文件commitlog消息主体以及元数据的存储主体；消费文件consumequeue消息消费队列，引入的目的主要是提高消息消费的性能；索引文件indexfile索引文件，提供了一种可以通过key或时间区间来查询消息。
　　RocketMQ采用的是混合型的存储结构，Broker单个实例下所有的队列共用一个数据文件（commitlog）来存储。
　　生产者发送消息至Broker端，然后Broker端使用同步或者异步的方式对消息刷盘持久化，保存至commitlog文件中。只要消息被刷盘持久化至磁盘文件commitlog中，那么生产者发送的消息就不会丢失。
　　Broker端的后台服务线程会不停地分发请求并异步构建consumequeue（消费文件）和indexfile（索引文件）。2数据文件
　　RocketMQ的消息数据都会写入到数据文件中，我们称之为commitlog。
　　所有的消息都会顺序写入数据文件，当文件写满了，会写入下一个文件。
　　如上图所示，单个文件大小默认1G，文件名长度为20位，左边补零，剩余为起始偏移量，比如00000000000000000000代表了第一个文件，起始偏移量为0，文件大小为1G1073741824。
　　当第一个文件写满了，第二个文件为00000000001073741824，起始偏移量为1073741824，以此类推。
　　从上图中，我们可以看到消息是一条一条写入到文件，每条消息的格式是固定的。
　　这样设计有三点优势：顺序写磁盘的存取速度相对内存来讲并不快，一次磁盘IO的耗时主要取决于：寻道时间和盘片旋转时间，提高磁盘IO性能最有效的方法就是：减少随机IO，增加顺序IO。对比随机和顺序读写在内存和磁盘中的表现《ThePathologiesofBigData》这篇文章指出：内存随机读写的速度远远低于磁盘顺序读写的速度。磁盘顺序写入速度可以达到几百兆s，而随机写入速度只有几百KBs，相差上千倍。快速定位因为消息是一条一条写入到commitlog文件，写入完成后，我们可以得到这条消息的物理偏移量。每条消息的物理偏移量是唯一的，commitlog文件名是递增的，可以根据消息的物理偏移量通过二分查找，定位消息位于那个文件中，并获取到消息实体数据。通过消息offsetMsgId查询消息数据消息offsetMsgId是由Broker服务端在写入消息时生成的，该消息编号包含两个部分：Broker服务端ipport8个字节；commitlog物理偏移量8个字节。
　　我们可以通过消息offsetMsgId，定位到Broker的ip地址端口，传递物理偏移量参数，即可定位该消息实体数据。3消费文件
　　在介绍consumequeue文件之前，我们先温习下消息队列的传输模型发布订阅模型，这也是RocketMQ当前的传输模型。
　　发布订阅模型具有如下特点：消费独立：相比队列模型的匿名消费方式，发布订阅模型中消费方都会具备的身份，一般叫做订阅组（订阅关系），不同订阅组之间相互独立不会相互影响。一对多通信：基于独立身份的设计，同一个主题内的消息可以被多个订阅组处理，每个订阅组都可以拿到全量消息。因此发布订阅模型可以实现一对多通信。
　　因此，rocketmq的文件设计必须满足发布订阅模型的需求。
　　那么仅仅commitlog文件是否可以满足需求吗？
　　假如有一个consumerGroup消费者，订阅主题mymactopic，因为commitlog包含所有的消息数据，查询该主题下的消息数据，需要遍历数据文件commitlog，这样的效率是极其低下的。
　　进入rocketmq存储目录，显示见下图：
　　消费文件按照主题存储，每个主题下有不同的队列，图中mymactopic有16个队列；每个队列目录下，存储consumequeue文件，每个consumequeue文件也是顺序写入，数据格式见下图。
　　每个consumequeue包含30万个条目，每个条目大小是20个字节，每个文件的大小是30万2060万字节，每个文件大小约5。72M。和commitlog文件类似，consumequeue文件的名称也是以偏移量来命名的，可以通过消息的逻辑偏移量定位消息位于哪一个文件里。
　　消费文件按照主题队列来保存，这种方式特别适配发布订阅模型。
　　消费者从broker获取订阅消息数据时，不用遍历整个commitlog文件，只需要根据逻辑偏移量从consumequeue文件查询消息偏移量，最后通过定位到commitlog文件，获取真正的消息数据。
　　这样就可以简化消费查询逻辑，同时因为同一主题下，消费者可以订阅不同的队列或者tag，同时提高了系统的可扩展性。4索引文件
　　每个消息在业务层面的唯一标识码要设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引），应用可以通过topic、key来查询这条消息内容，以及消息被谁消费。
　　由于是哈希索引，请务必保证key尽可能唯一，这样可以避免潜在的哈希冲突。订单IdStringorderId1234567890；message。setKeys（orderId）；
　　从开源的控制台中根据主题和key查询消息列表：
　　进入索引文件目录，如下图所以：
　　索引文件名fileName是以创建时的时间戳命名的，固定的单个IndexFile文件大小约为400M。
　　IndexFile的文件逻辑结构类似于JDK的HashMap的数组加链表结构。
　　HashMap数据结构
　　索引文件主要由Header、SlotTable（默认500万个条目）、IndexLinkedList（默认最多包含2000万个条目）三部分组成。
　　假如订单系统发送两条消息A和B，他们的key都是1234567890，我们依次存储消息A，消息B。
　　因为这两个消息的key的hash值相同，它们对应的哈希槽（深黄色）也会相同，哈希槽会保存的最新的消息B的索引条目序号，序号值是4，也就是第二个深绿色条目。
　　而消息B的索引条目信息的最后4个字节会保存上一条消息对应的索引条目序号，索引序号值是3，也就是消息A。5写到最后
　　DatabasesarespecializingtheonesizefitsallapproachnolongerappliesMongoDB设计哲学
　　RocketMQ存储模型设计得非常精巧，笔者觉得每种设计都有其底层思考，这里总结了三点：完美适配消息队列发布订阅模型；数据文件，消费文件，索引文件各司其职，同时以数据文件为核心，异步构建消费文件索引文件这种模式非常容易扩展到主从复制的架构；充分考虑业务的查询场景，支持消息key，消息offsetMsgId查询消息数据。也支持消费者通过tag来订阅主题下的不同消息，提升了消费者的灵活性。
　　原文链接：https：mp。weixin。qq。comsUKahbGnJwOAPr3CD4ZVFQ