不知具体从何时起“计算和存储分离”常常出现在讨论中。要了解计算和存储分离到底是什么，那么我们就需要先理解什么是计算，什么是存储。

计算这个单词有运算之义，和数学的关系密不可分。大家回想一下以前数学考试的时候，那一道道的数学题怎么得出结果的，这一过程其实称之为计算。那我们这里谈论的其实是计算机计算，所以我们可以得出通过计算机得到问题的结果这个就叫做计算机计算，也就是我们这里所谈论的”计算”。

对于存储来说，这个概念比较难以定义，很多人都简单的认为这个是硬盘，U盘等。但其实在我们的计算机计算过程中和存储是密不可分的，我们知道CPU是由控制器、运算器和寄存器组成的，我们在运行一段程序的时候我们的指令是存储在我们的存储器的，我们所执行的每一个步骤都和存储分离不开。

计算机中计算和存储其实是分离不开的，我们想想如果将计算和存储分离开来，通过高速网络进行交互，那么我们的CPU的每一条指令都需要通过网络传输，而我们的网络传输和我们当前的CPU速度完全不匹配，所以我们的计算和存储分离其实是一个伪需求，当然在未来的某一天如果我们的网络传输的时间可以忽略不计，计算和存储分离也就能真正的实现了。

那这里我们来做一个最终的定义，我们后面所讲的“存储”都是需要持久化的，可以是U盘，硬盘，网盘等等，我们所讲的“计算”其实就是我们的计算过程所需要的CPU和内存等。

为何需要计算和存储分离

计算和存储分离并不是现在才出现的一个新名词，在20年前就有NAS-网络附加存储这个东西，本质上也就是使用TCP/IP协议的以太网文件服务器。

谷歌摒弃了之前的观念“移动存储到计算”，采取了“移动计算到存储的观念”，将计算和存储耦合了，因为当时的网络速度对比现在来说慢了几百倍，网络速度跟不上我们的需要。在在典型的MapReduce部署中计算和存储都在同一个集群中进行，比如后续的hadoop。这里其实也就是用本地IO速度来替换网络传输速度。

随着技术的进步，我们的网络速度也越来越快，我们的瓶颈不再是网络速度，但是我们的磁盘I/O速度却没有明显的速度增长，计算和存储融合的架构缺点也再逐渐暴露：

• 机器的浪费：业务是计算先达到瓶颈的，还是存储先达到瓶颈的。这两种情况往往是不一样的，往往时间点也是不一样的。在架构里就存在一定的浪费。如果说计算不够，也是加一台机器；存储不够，还是加一台机器。所以这里就会存在很多浪费。
• 机器配比需要频繁更新：一般来说在一个公司内机器的配型比较固定比如提供好几种多少核，多少内存，多少存储空间等等。但是由于业务在不断的发展，那么我们的机器配型也需要不断的更新。
• 扩展不容易：如果我们存储不够了通常需要扩展，计算和存储耦合的模式下如果扩展就需要存在迁移大量数据。

由于计算和存储耦合的缺点越来越多，并且网络速度越来越快，现在架构又在重新向计算和存储分离这一方向重新开始发展。

谁在使用计算和存储分离

那么其到底在哪些地方做了使用呢？其影响比较大的有两块，一个是数据库，另外一个是消息队列，接下来我会具体讲下这两块到底是怎么利用“计算和存储分离”的。

• 数据库

一谈到数据库我们不得不想到MySql,这个应该也是大家最熟悉的数据库，下面是Mysql的一个主从架构图：

可以看见我们的master接收数据的变更，我们的从数据库读取binlog信息，重放binlog从而达到数据复制。在Mysql的主从架构中有很多问题：

1. 主库的写入压力比较大的时候，主从复制的延迟会变得比较高，由于我们其复制的是binlog，他会走完所有的事务。
2. 增加从节点速度慢，由于我们需要将数据全量的复制到从节点，如果主节点此时存量的数据已经很多，那么扩展一个从节点速度就会很慢高。
3. 对于数据量比较大的数据库，备份的速度很慢。
4. 成本变高，如果我们的数据库的容量比较大，那么我们相应的所有从节点的容量都需要和猪数据库一样大,我们的成本将会随着我们所需要从数据库的数量进行线性增加。

这一切的问题好像都在指引着我们走向计算和存储分离的道路，让所有的节点都共享一个存储。AWS就宣布推出Aurora。这是一个面向亚马逊关系数据库服务（RDS）的兼容MySQL的数据库引擎。

现在很多的数据库都在逐渐向“计算和存储分离”靠拢，包括现在的PolarDB、OceanBase ，TiDB等等。所以“计算和存储分离”应该是未来数据库的主要发展方向。

• 消息队列

消息队列不论是Kafka还是RocketMQ其设计思想都是利用本地机器的磁盘来进行保存消息队列，这样其实是由一定的弊端的：

1. 数据有限，使用者两个消息队列的同学应该深有感触，一般会服务器保存最近几天的消息，这样的目的是节约存储空间，但是就会导致我们要追溯一些历史数据的时候就会导致无法查询。
2. 扩展成本高，在数据库中的弊端在这里同样也会展现。

针对这些问题ApachePulsar出现了，pulsar最初由Yahoo开发，在18年的时候一举将kafka连续两年InfoWorld最佳开源数据平台奖夺了过来。

在Pulsar的架构中，数据计算和数据存储是单独的两个结构：

• 数据计算也就是Broker，其作用和Kafka的Broker类似，用于负载均衡，处理consumer和producer等，如果业务上consumer和producer特别的多，我们可以单独扩展这一层。
• 数据存储也就是Bookie，pulsar使用了Apache Bookkeeper存储系统，并没有过多的关心存储细节，这一点其实我们也可以借鉴参考，当设计这样的一个系统的时候，计算服务的细节我们需要自己多去思考设计，而存储系统可以使用比较成熟的开源方案。

Kafka最新的一些提议，也在向这些方面靠拢，比如也在讨论是否支持分层存储，当然是否采用“计算和存储分离”架构这个也是不一定的，但是“计算和存储分离”的方向也应该是消息队列未来发展的主要方向。

随着云原生的发展“计算和存储分离”，在各种系统中出现的次数越来越多，希望大家读完这篇文章能对其有个简单的认识。