![99c1978914aaa39ab11f9bd2cac20fbb.png](https://i-blog.csdnimg.cn/blog_migrate/1b19172081a31b6d36c8b66f900fc868.jpeg)
MQ初窥门径
全称(message queue)消息队列,一个用于接收消息、存储消息并转发消息的中间件
应用场景
用于解决的场景,总之是能接收消息并转发消息
- 用于异步处理,比如A服务做了什么事情,异步发送一个消息给其他B服务。
- 用于削峰,有些服务(秒杀),请求量很高,服务处理不过来,那么请求先放到消息队列里面,后面按照能力处理,相当于蓄水池。
- 应用解耦、消息通讯等等
总之MQ是可以存放消息并转发消息的中间件,场景取决于拿这个能力去解决什么问题
MQ概念模型
MQ向别人承诺的场景是接收消息,存储,并可以转发消息
接收消息
接收消息,那么接收谁的消息,为了说明这个问题,那么mq需要引入一个概念,叫做生产者,也就是发送消息的服务,否则没有办法来区分是谁发的消息,生产者通过网络发送消息就可以,中间的细节我们先不探讨。
那么还有一个问题就是消息发送给谁?
- 我在发送消息的时候,指明我要发送给谁,就像发送短信一样,你需要指明你要发送给谁?
- 这种方案在使用中是有问题的,因为在现在业务很多场景中, 发送方其实根本不知道对方是谁,他只是将自己的状态发送出来,那么谁需要这个消息,谁就接收,第二个如果指明了接收方,那么以后增加一个接收方就要改一下配置或者代码,将发送消息的人跟接收消息的人绑定在一起了
- 那么有没有方案,解耦的最好办法就是中间人,也叫中间层,我只发送给第三方,谁要消息,问第三方要,那么相当于我把发送的目标改为发送给第三方,这里的第三方就是mq,为了说明说明发送的地方,mq引入了topic的概念,发送方把消息发送到mq指定的一个通道中,以后谁想要这个消息,就跟mq说我想要这个通道的消息,也就是发送方发送的消息。
消费消息
消费消息,那么同理的一个问题,谁消费消息,为了说明那么mq需要引入一个概念,叫做消费者,也就是消费消息的服务,否则没有办法来区分是谁在接收消息,消费者通过网络接收消息就可以了,中间的细节我们先不探讨。
那么问题来了,消费者怎么说明消费谁的消息,上文已经说了,通过指明mq的topic,来决定我要哪一类消息。
至此我们总结一下最后的模型
![ddc658e74c82846801681f8cc8a8d271.png](https://i-blog.csdnimg.cn/blog_migrate/18dedb2501a2dbc3f01359f04f712539.jpeg)
也就是最后生产者和消费者通过MQ的topic概念来实现解耦。
存储
说到存储,其实效率才是最主要的,容量不是我们关心的,但是说到存储,不只是mq,所有需要高效率的存储其实最后利用的核心都是一样的。
- 随机写转换成顺序写
- 集中刷盘
为什么随机写要转换为顺序写?
第一 现在主流的硬盘是机械硬盘
第二 机械硬盘的机械结构一次读写时间 = 寻道时间 + 旋转延迟 + 读取数据时间
那么寻道时间比较长,如果是顺序写,只需要一次寻道时间,关于机械硬盘整个过程,读者可自行google。
![6120453e09bdcbc16cfc4a1923393842.png](https://i-blog.csdnimg.cn/blog_migrate/e2d6917b03166aa2750b9f9adfc63aff.jpeg)
为什么集中刷盘?
因为每次刷盘都会进行系统调用,第二还是跟硬盘的本身属性有关,无论是机械硬盘还是ssd按照一定块刷盘会比小数据刷盘效率更好
kafka
为什么先说kafka的存储,因为kafka是第一个高性能的消息中间件,其中rocketmq也是借鉴于它,所以我们先说。
![2ab8676615a68afeaf23b7f67bbf4380.png](https://i-blog.csdnimg.cn/blog_migrate/1f8419cee17b8a01300430222baf3ce6.jpeg)
先给出最终模型变化图。
- 为什么引入消费组概念?
- 上一次模型图我们还没有消费组,那么引入消费组,是因为现在一个服务都有很多实例在运行,消费组是对这群一群机器的一个划分,他还是一个概念而已。
- mq内部也发生了变化,一个topic后面又对应了很多partition,partition也是一个概念,他只不过是把一个topic分成了很多份,每一份叫一个partition,你高兴也可以叫他xxx,那么我们来说说为什么要分成很多份,一份不行吗?
- 因为现在一个服务有很多实例在运行,如果topic只有一份的话,那么所有的实例都会来消费消息,并且都是抢占我们一个topic,这不可避免引入了多实例竞争,以及他们之间怎么协调,一堆问题需要关注解决,现在我把topic分成了很多份,每一份只给一个实例,那么就不会引入各实例之间的竞争问题了,简化了mq的问题。
- 生产组的引入也是一样的,只不过是一组机器的一个概念,一个逻辑的划分,生产者发送消息原先是发往topic,那么现在topic分成了很多份,生产者发送消息,需要说明发往哪个partition或者随意分配都可以,只不过最终发送的消息,会到一个topic下的一份里面。无论使用哪种映射方式都可以。
那么模型出来了,我们说说存储的问题。
![a2a226bc41f5db433551db0659cb37f3.png](https://i-blog.csdnimg.cn/blog_migrate/f9e967e087c6b357a9d93a57c0eb4370.jpeg)
对于kafka,一个partition对应一个文件,每次消息来都是顺序写这个文件。并且是定时刷盘,而不是每次写都刷盘,所以kafka的写非常高效。
rocketmq
![c7d186dcbfbb53d75782f26512a3f243.png](https://i-blog.csdnimg.cn/blog_migrate/8ef1c3fa27d0b24d4ab37b07566191ce.jpeg)
上文我们说了rocketmq借鉴于kafka,所以存储借鉴了kafka,但是rocketmq不是仅仅把partition改成了ConsumeQueue,在这里做了变化,原先kafka,里面partition存储的是整个消息,但是现在ConsumeQueue里面是存储消息的存储地址,但是不存储消息了。
![f236a068e1f4e5b1da13b1a08daaf205.png](https://i-blog.csdnimg.cn/blog_migrate/60437862684df586202642b760494edb.jpeg)
现在每个ConsumeQueue存储的是每个消息在commitlog这个文件的地址,但是消息存在于commitlog中。
也就是所有的消息体都写在了一个文件里面,每个ConsumeQueue只是存储这个消息在commitlog中地址。
存储对比
- 消息体存储的变化
- 那么我们先来看看kafka,假设partition有1000个,一个partition是顺序写一个文件,总体上就是1000个文件的顺序写,是不是就变成了随机写,所以当partition增加到一定数目后,kafka性能就会下降。而rocketmq是把消息都写到一个CommitLog文件中,所以相当于一个文件的顺序写。
- 为什么索引文件(ConsumeQueue)的增加对性能影响没有那么partition大?
- (kafka也有索引文件,在这里只是想说明索引文件的增加跟partition增加的区别)
- 虽然rocketmq是把消息都写到一个CommitLog文件中,但是按照上面的实例会有1000个ConsumeQueue,也就是一千个文件,那么为什么就没有把顺序写变成随机写,带来性能的下降呢?首先就要介绍linux的pagecache
![3ace1192b297f224ffc8843311aa8489.png](https://i-blog.csdnimg.cn/blog_migrate/2b106b8efc3201da40f00304d8bc8333.jpeg)
- 我们平常调用write或者fwrite的时候,数据还没有写到磁盘上,只是写到一个内核的缓存(pagecache),只有当我们主动调用flush的时候才会写到硬盘中。或者需要回写的pagecache占总内存一定比例的时候或者一个应该回写的page超过一定时间还没有写磁盘的时候,内核会将这些数据通过后台进程写到磁盘中(总结就是达到一定比例,或者多长时间还没有回写,会被内核自动回写)。
- 然后我们现在来看看为什么大量索引文件的顺序写没有像partition一样导致性能明显下降。ConsumeQueue只存储了(CommitLog Offet + Size + Message Tag Hashcode),一共20个字节,那么当commitlog定时任务刷盘之后,应该回写的pagecache的比例就会下降很多,那么ConsumeQueue的部分可以不用刷盘,就相当于ConsumeQueue的内容会等待比较长的时间聚合批量写入,而kafka每个partition都是存储的消息体,因为消息体都相对较大,基本在kb之上。
- 当一个partition刷盘的时候,应该回写的pagecache的比例降低的并不多,不能阻止其他partition的刷盘,所以会大量存在多个partition同时刷盘的场景,变成随机写。但是rocketmq消息都会写入一个commitLog,也就是顺序写。
所以我们总结下这个点:
1、consumerQueue消息格式大小固定(20字节),写入pagecache之后被触发刷盘频率相对较低。就是因为每次写入的消息小,造成他占用的pagecache少,主要占用方一旦被清理,那么他就可以不用清理了。
2、kafka中多partition会存在随机写的可能性,partition之间刷盘的冲撞率会高,但是rocketmq中commitLog都是顺序写。
end:如果你觉得本文对你有帮助的话,记得关注点赞转发,你的支持就是我更新动力。