RocketMQ源码阅读(四)-消息存储

前言

接下来会介绍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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容

  • RocketMQ的消息存储过程非常复杂, 本文先介绍存储模块中几个重要对象. 1. MappedFile 对Map...
    _呆瓜_阅读 2,188评论 1 4
  • 前文已经介绍了消息存储中使用到的充要对象, 本文分析一下消息介绍的主流程. 另外, 此篇主要分析消息存储主流程的代...
    _呆瓜_阅读 1,220评论 0 1
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,585评论 18 139
  • 0.前言 RMQ对于消息持久化的方式是顺序写到本地磁盘文件,相对于持久化到远程的数据库或者KV来说,往本地磁盘文件...
    lambdacalculus阅读 2,609评论 1 6
  • # # 数据保全api文档数据保全api文档 ##3.1 获取用户授权令牌 ###接口名称:getUserToke...
    jinganchuqi阅读 221评论 0 0