前言
接下来会介绍RocketMQ的消息存储, 本文先对RocketMQ的整体设计和组件进行简单介绍,后续会针对细节进行源代码的分析.
目前MQ的存储方式主要是三种方式:
- 分布式KV存储(levelDB, RocksDB, redis)
- 文件系统
- 关系数据库
这几种存储方式从效率来看, 文件系统>kv存储>关系型数据库, 因为直接操作文件系统肯定是最快的, 而关系型数据库一般的TPS相比于kv数据库会更低一些, 所以如果追求效率就直接操作文件系统. 但是如果从可靠性和易实现的角度来说, 则是关系型数据库>kv存储>文件系统, 消息存在db里面非常可靠, 但是性能会下降很多, 所以具体的技术选型都是需要根据自己的业务需求去考虑.
1.RocketMQ的存储架构
1.1 存储特点
(1) 消息主体以及元数据都存储在**CommitLog**当中
(2) Consume Queue(相当于kafka中的partition, 但又有不同)是一个逻辑队列, 存储了这个Queue在CommiLog中的起始offset, log大小和MessageTag的hashCode.
(3) 每次读取消息队列先读取consumerQueue,然后再通过consumerQueue去commitLog中拿到消息主体.
1.2 设计初衷
RocketMQ的设计理念很大程度借鉴了kafka, 所以介绍下kafka的存储结构设计:
和RocketMQ类似, 每个Topic有多个partition(queue),kafka的每个partition都是一个独立的物理文件, 消息直接从里面读写.
根据之前阿里中间件团队的测试, 一旦kafka中Topic的partitoin数量过多, 队列文件会过多, 会给磁盘的IO读写造成很大的压力, 造成tps迅速下降.
所以RocketMQ进行了改良, consumerQueue中只存储很少的数据, 消息主体都是通过CommitLog来进行读写.
1.3 优缺点
- 优点: 队列轻量化, 单个队列数据量非常少. 对磁盘的访问串行化, 避免磁盘竟争, 不会因为队列增加导致IOWAIT增高.
- 缺点: a.写虽然完全是顺序写, 但是读却变成了完全的随机读. 读一条消息, 会先读ConsumeQueue, 再读CommitLog, 增加了开销. b.要保证CommitLog与ConsumeQueue完全的一致, 增加了编程的复杂度.
1.4 如何克服缺点
1).充分利用page cache降低读数据的时间开销. 读取时尽可能让其命中page cache, 减少IO读操作, 所以内存越大越好. 如果系统中堆积的消息过多, 读数据要访问磁盘会不会由于随机读导致系统性能急剧下降, 答案是否定的.
访问page cache 时, 即使只访问1k的消息, 系统也会提前预读出更多数据, 在下次读时, 就可能命中内存.
随机访问Commit Log磁盘数据, 系统IO调度算法设置为NOOP方式, 会在一定程度上将完全的随机读变成顺序跳跃方式, 而顺序跳跃方式读较完全的随机读性能会高5倍以上.
另外4k的消息在完全随机访问情况下, 仍然可以达到8K次每秒以上的读性能.
由于Consume Queue存储数据量极少, 而且是顺序读, 在PAGECACHE预读作用下, Consume Queue的读性能几乎与内存一致, 即使堆积情况下. 所以可认为Consume Queue完全不会阻碍读性能.
2).Commit Log中存储了所有的元信息, 包含消息体, 类似于Mysql、Oracle的redolog, 所以只要有Commit Log在, Consume Queue即使数据丢失, 仍然可以恢复出来.
2.底层实现
2.1 MappedByteBuffer
RocketMQ中的文件读写主要就是通过MappedByteBuffer进行操作, 来进行文件映射. 利用了nio中的FileChannel模型, 可以直接将物理文件映射到缓冲区, 提高读写速度.
2.2 page cache
通俗的说：pageCache是系统读写磁盘时为了提高性能将部分文件缓存到内存中, 下面是详细解释：
page cache:这里所提及到的page cache, 在我看来是linux中vfs虚拟文件系统层的cache层, 一般pageCache默认是4K大小, 它被操作系统的内存管理模块所管理, 文件被映射到内存, 一般都是被mmap()函数映射上去的.
mmap()函数会返回一个指针, 指向逻辑地址空间中的逻辑地址, 逻辑地址通过MMU映射到page cache上.
关于内存映射的一篇博客：
内存映射
总体来说, RocketMQ通过将文件映射到内存上, 直接操作文件, 相比于传统的io(首先要调用系统IO, 然后要将数据从内核空间传输到用户空间),避免了很多不必要的数据拷贝, 所以这种技术也被称为 零拷贝 ,具体可见IBM团队关于零拷贝的博客：
零拷贝
3.消息存储主流程
3.1 CommitLog消息存储
时序图如下:
3.2 ConsumeQueue
上述的消息存储只是把消息主体存储到了物理文件中, 但是并没有把消息处理到consumeQueue文件中, 那么到底是哪里存入的？
任务处理一般都分为两种：
- 一种是同步, 把消息主体存入到commitLog的同时把消息存入consumeQueue, rocketMQ的早期版本就是这样处理的.
- 另一种是异步处理, 起一个线程, 不停的轮询, 将当前的consumeQueue中的offSet和commitLog中的offSet进行对比, 将多出来的offSet进行解析, 然后put到consumeQueue中的MapedFile中.
问题：为什么要改同步为异步处理？应该是为了增加发送消息的吞吐量.
3.3 刷盘策略
调用MapedFile的appendMessage后, 也只是将消息装载到了ByteBuffer中, 也就是内存中, 还没有落盘. 落盘需要将内存flush到磁盘上, 针对commitLog, rocketMQ提供了异步落盘和同步落盘两种落盘方式.
4. 消息索引
RocketMQ提供了一种消息查找的服务, 可以根据起始时间、topic和key来查询消息. 为了实现这个查找功能, RocketMQ为队列中的消息建立了索引, 通过索引去查找消息.
5. 总结
RocketMQ基于kafka的设计思想对消息存储做了大量的实践和优化. 本文对RocketMQ的存储组件进行了大概的介绍, 后问会对CommitLog, ConsumeQueue, IndexService等实现源码进行深入分析.
参考:
http://blog.csdn.net/mr253727942/article/details/55805876?utm_source=tuicool&utm_medium=referral