36 云原生：业界MQ的计算存储分离
存算分离架构
存算一体架构如下
存算分离架构则是目前实现弹性消息队列集群的主要技术方案
存算分离架构的优点是计算层为无状态，因此计算层的扩缩容就很方便。缺点是架构变复杂，代码实现难度也提升很多，日常的运维、研发的学习成本也会相应提高。另外计算层和存储层的交互从本地调用变为了网络协议的调用，性能上会有一些下降。
存算分离架构最大的好处就是集群变得更加弹性。从终态来说，没有存算分离，消息队列架构就无法 Serverless 化，也就无法做到快速扩缩容。从成本结构的角度来看，没法快速扩缩容，那么就无法提高集群的利用率，也就无法很好地降低成本。
实现存算分离架构的技术思考
如何选择合适的存储层引擎
因为分布式存储服务一般会提供多语言的流式写入的 API 进行数据读写，读写性能较高，比较适合消息队列的数据特点。所以从业界落地的角度来看，分布式存储服务用得比较多。比如 Pulsar 的存储层使用的是 BookKeeper，RocketMQ 5.0 的存储层用的是原先的 Broker 集群。
存储层：分区存储模型的设计
但是在存算分离的架构中，基本都是每个分区一个“文件”的方案。主要是出于数据的读写性能考虑。在存算分离的架构中，我们是通过网络协议从存储层读取数据的。
如果数据存储在一份文件中，则存储层在读取数据时就需要维护二级索引，并启动随机读，在性能上会有一定的降低
所以合理的方案如下图所示，不同的分区在存储层有独立的“文件”存储，然后顺序读写不同的段文件
计算层：弹性无状态的写入
分区的数据写入到存储层，依赖存储层多副本存储的能力实现数据的可靠存储。从技术来看，副本并没有被省掉，只是将副本概念下沉到了存储层而已
业界主流存算分离架构分析
RocketMQ 5.0 就是在原先 Broker 集群的基础上添加了一个 Proxy 组件。
前的 Proxy 组件只是转发层，不处理任何计算和存储的逻辑。集群实际意义上的计算和存储逻辑，都是在 Broker 集群上完成的。这就是我们前面所说的，当前 RocketMQ 5.0 的架构不是真正意义上的存算分离架构的原因。更准确的说法是，RocketMQ 5.0 只是从当前存算一体的架构往存算分离架构演化走出了第一步。
Pulsar 存算架构分析
Pulsar 计算层的分区都是单副本的，即没有副本的概念。每个 Pulsar 分区底层由多个 Ledger 组成，每个 Ledger 只包含一个分区的数据。每个 Ledger 有多个副本，这些 Ledger 副本分布在 BookKeeper 集群中的多个节点上
因为计算层就都是无状态的，迁移起来就很快，直接修改元数据即可
同时，为了提高负载均衡和迁移的效率，Pulsar 引入了 Bundle 的概念。参考图示，Bundle 是处于 Namespace 和 Topic 之间的一个概念，它是用来组织多个 Topic 的一个逻辑概念。即一个 Namespace 有多个 Bundle，一个 Bundle 里面有多个 Topic。
