深入浅出消息队列----【核心之存储（1）】

本文仅是文章笔记，整理了原文章中重要的知识点、记录了个人的看法
文章来源：编程导航-鱼皮【yes哥深入浅出消息队列专栏】

这一篇要深入了解 Broker 关于消息的存储到底是如何实现的。

消息的存储非常重要，因为消息队列有一个很关键的功能就是削峰填谷，简单来说就是在大流量（如双十一场景），一下子涌入大量的用户，造成了请求高峰，使得系统压力剧增。

这时候一个很好的办法就是把相关请求发送至消息队列，然后直接返回给用户成功，诸如：“业务受理成功，由于当前流量较高，到账时间约为xx-xx分钟”这样的话术。

然后让系统平缓、匀速地拿取消息队列里面的消息进行业务处理。

然而这就需要保证排队的消息存储的可靠性。

比如现在排了 1000 条消息，那我们最后必须要能处理到这 1000 条消息，不能处理了 500 条消息，然后消息队列突发重启了，后面的 500 条消息就没了，那可就 GG 了。

所以需要思考下：Broker 里的消息，到底应该存在哪里？

消息存哪？

存储数据一般我们第一个想到的是数据库，比如 MySQL。

所以把消息存储到数据库里？

这不太合适。

上面说了消息队列需要满足削峰填谷的需求，也就是消息存储的性能要好，快速存储消息返回存储结构，这样才不会堵塞业务处理。

不然存个消息要存半天，那跟直接处理业务有什么区别？别谈削峰了，自己就是那座峰。

那把消息存入数据库性能好吗？

众所周知，性能不好，性能好还要什么缓存？还要什么 Redis？

提到 Redis 了，虽然 Redis 性能好，但是它不可靠啊！

前面提到的，存储消息队列的消息，一定需要保证它能被消费到，这样才不会影响正常业务，如果存储不可靠，丢了消息，麻烦可就大了。

那还能存在什么地方呢？

本地硬盘。

MySQL 数据实际存储的地方就是本地硬盘，Redis 持久化的数据也是在本地硬盘上。

直接绕过他们，不给中间商赚差价，直接将消息写入本地硬盘的文件上。

虽然单个硬盘也不可靠，但是现在基本都是 RAID，即多块硬盘组成逻辑上的一块硬盘，简单理解就是有备份。

commitlog

那么消息是以怎样的格式存储到文件里的，最简单的方式就是一行一行的写咯。就像记事本中的一样：

那 RocketMQ 是这样存储消息的吗？

答案：是的！

这个存储消息的文件在 RocketMQ 中叫做 commitlog。

从上面的图中可以发现，这里有两个问题：

1. 每条消息的大小都是不固定的。
2. 不同的 topic 消息为什么都存储在一哥 commitlog 中呢？

这里涉及到了计算机组成原理中的机械硬盘结构的特性。

机械硬盘

学过计算机组成原理的对这张图片应该不陌生，常考！

盘片的结构

1. A 就是磁道，盘面就是由磁道这样的一组同心圆构成，注意是标红的不为，是个环，有横截面的。
2. B 是扇面。
3. C 就是扇区，每个磁道都会被划分为一组扇区，每个扇区包含相等数量的数据位，一般为 512 字节，是硬盘存储数据最基本的单位。
4. D 是簇，即多个扇区组成的，像 DOS 就是以簇为单位为文件分配磁盘空间的。

如果要访问硬盘的数据，就需要将磁头放到对应数据存储的扇区上。

关于数据的访问时间有两个影响因素：

1. 寻道时间：盘片的表面是磁性的，盘片随着主轴旋转而转动，当要访问某个扇区的时候首先要转动磁头臂找到对应的磁道。
2. 旋转时间：这时盘片还是在旋转中，磁头可以感知到下方数据位上的值，等旋转到目标扇区的时候就晓得该读/写数据了。

所以在物理层面上，如果存储在磁盘上的数据在同一个磁道且相邻的扇区，那么根据硬盘的机械运行归集，读/写的速度就会非常快（省略寻道时间，顺应旋转的方向），甚至可以媲美内存的读写速度！

这就是常说的顺序读和顺序写。

对应到消息存储上，所有的消息无论是哪个 topic 都写入同一个文件，并且都是顺序追加写入，那么对应到硬盘上就是顺序写！（基本上一个的文件的内容，如果空间足够，那么都是连续的）。

这就大大提高了消息队列写消息的性能。

如果将不同的 topic 写入不同的文件中，就无法保证这些文件在硬盘上的物理位置是连续的，就会降低读写速度。

这也是面试常常会问道 RocketMQ 为什么性能好的原因之一：顺序写。

顺序写在很多地方都有应用，比如 MySQL 的 redo log。

原文地址：https://blog.csdn.net/qq_52354698/article/details/140551258

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！