05｜存储：消息数据和元数据的存储是如何设计的？

作者回复: 从技术上来看，Dubbo肯定也能做，而且还有facebook的thrift等rpc框架也能做。技术上的差异，我们可以写出很多，比如你说的多语言，协议、性能等等，就先不展开。 但是我理解这个问题可以跳出技术的角度来看。 我会认为主要是社区影响力、技术生态丰富度、研发人员的认知接受度的差异。我认为主要是前两点。 GRPC当前可以说得业界RPC框架的代表了，业界接受度最高。此时带来的结果是，各个社区开源组件对GRPC的支持就很友好，比如Service Mesh，比如多个语言的SDK支持等等。 此时如果选择用GRPC 就会天然和社区的组件联通，减少了很多重复开发，对接的成本。有强强联合的效果。而如果用其他的组件，就会多很多对接、重复开发、客户适配的问题。

作者回复: 你好啊~ 如果仅仅从文件数量的角度来看，就会认为可能有这个问题。但是生产环境中却很少会出现因为索引文件导致硬盘的压力多大的情况。原因是顺序写退化到随机写其实需要满足两个条件： 1. 文件数量很多。 2. 这些文件同时都有较大量的读写。 所以核心点在于文件的读写频率和读写数据量的差别。从技术上来看，索引文件不会产生这个问题主要有下面三个原因： 1. 索引文件的读写频率相对数据文件低很多，一般不会存在大量同时的读写。 2. 索引文件的数据量很小，即使大量读写，在短时间内就完成了，不会造成持续的压力。 2. 索引的数据因为数据量较小，一般会缓存到内存中，所以读写对硬盘的压力不大。 所以在大部分情况下，索引文件不会导致顺序写退化到随机写。但是从理论上看，非常极端的场景下是有这个可能的。

作者回复: 你好啊，在我看来这里是有一种细微的差别的。以kafka为例： 1. 第二种方案，提交了offset后，还可以通过重置offset，来消费到之前消费过的数据。此时就有一种可能，就是客户端错误的重置了offset，此时就会出现重复消费消息的情况。这种场景在kafka里面经常会遇到，这也是kafka无法保证消费不重复的原因所在。 2. 如果第三种，当ack掉这个消息后，这个消费分组就无法再通过重置offset等操作来消费到已经消费过的数据。只要消息被ack，此时消息就永远(除非提供unack的功能)无法在这个消费分组被重复消费到。此时就避免了同一个消费分组的消息被重复消费的情况。从而提供了不重复消费的语义。 以上，就是我认为kafka是第二种方案的原因

作者回复: 因为数据是写入到硬盘的。 如果同时有很多个文件在同时往硬盘去读写的话。从硬盘的角度来看的话，就是同时在硬盘的不同位置去读写，此时硬盘就得去调度不同位置的读写。即使是SSD和NVME的盘，这种在频繁的在硬盘不同位置的读写就是会降低性能。从硬盘角度来看，就是在不同位置的随机读写。

作者回复: 是的，技术上确实是这个原理，但是大部分情况下其实还好。 因为只有在很极端的情况，比如分区很多，并且都存在读写的场景才会触发。 在现网，做好运营的话，控制好单机的分区数，触发的概率不大。 - -

作者回复: 是的，这里的表达有点问题。我想表达的意思是”缺点是同一个分区的数据一般会在文件中的不同位置，或者不同的文件段中“。我修改一下，谢谢提醒~ 感谢感谢

作者回复: 有这个规划的。我们先把理论讲完，理论扎实了，再一起来实战，效率会更高，效果也更好

作者回复: 区别还是蛮大的，你可以先想想区别是什么。提示一下，可以从功能层面分析底层存储结构的区别

作者回复: 从工程的角度来看，消息队列是一个分布式存储系统。而分布式存储系统，底层的技术选型和设计要点其实是差不多的，有很多共性。只是形态和需求不一样，导致实现有差别。