聊聊计算和存储分离

1.背景

这篇文章是我一直想写的一篇，由于“计算和存储分离”最近几年在你们的视野中出现得愈来愈多，但其实不少对于其到底表明着什么也是模糊不清，这里我查阅了不少的资料再结合平时本身的理解，聊聊到底什么是“计算和存储分离”

2.何为计算？何为存储？

要了解计算和存储分离究竟是什么，那么咱们就须要理解什么是计算，什么是存储。 计算这个单词有运算之义，和数学的关系密不可分。你们回想一下之前数学考试的时候，那一道道的数学题怎么得出结果的，这一过程其实称之为计算。那咱们这里谈论的实际上是计算机计算，因此咱们能够得出经过计算机获得问题的结果这个就叫作计算机计算，也就是咱们这里所谈论的"计算"。

对于存储来讲，这个概念比较难以定义，不少人都简单的认为这个是硬盘，U盘等。但其实在咱们的计算机计算过程当中和存储是密不可分的，咱们知道CPU是由控制器、运算器和寄存器组成的，咱们在运行一段程序的时候咱们的指令是存储在咱们的存储器的，咱们所执行的每个步骤都和存储分离不开。好比咱们之前考试的时候选择题，你们关心的只是你选择是否正确，不会关心你的运算过程，你的运算结果能够看作是硬盘，须要持久化给评卷人看，而你的计算过程相似草稿纸，虽然不须要给评卷人看，可是同样的是实实在在的写在了纸上。

上面咱们说了在计算机中计算和存储实际上是分离不开的，咱们想一想若是将计算和存储分离开来，经过高速网络进行交互，那么咱们的CPU的每一条指令都须要经过网络传输，而咱们的网络传输和咱们当前的CPU速度彻底不匹配，因此咱们的计算和存储分离实际上是一个伪需求，固然在将来的某一天若是咱们的网络传输的时间能够忽略不计，计算和存储分离也就能真正的实现了。

计算和存储分离既然是一个伪需求，那为何这么多人还在说起呢？那就须要从新再定义一下他们的含义，咱们将计算过程当中的存储概括为计算，只关注问题和结果，这就是咱们新的“存储”的定义，就相似咱们考试的时候草稿纸不须要存放，能够任意撕毁同样。

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

3.为什么须要计算和存储分离

计算和存储分离并非如今才出现的一个新名词，在20年前就有NAS-网络附加存储这个东西，本质上也就是使用TCP/IP协议的以太网文件服务器。当时若是想要大规模的存储，就会让服务器将数据保存到NAS这个上面，可是NAS价格及其昂贵，而且扩展比较困难，NAS也就不适用于高速发展的互联网应用。

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

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

• 机器的浪费：业务是计算先达到瓶颈的，仍是存储先达到瓶颈的。这两种状况每每是不同的，每每时间点也是不同的。在架构里就存在必定的浪费。若是说计算不够，也是加一台机器；存储不够，仍是加一台机器。因此这里就会存在不少浪费。
• 机器配比须要频繁更新：通常来讲在一个公司内机器的配型比较固定好比提供好几种多少核，多少内存，多少存储空间等等。可是因为业务在不断的发展，那么咱们的机器配型也须要不断的更新。
• 扩展不容易：若是咱们存储不够了一般须要扩展，计算和存储耦合的模式下若是扩展就须要存在迁移大量数据。

因为计算和存储耦合的缺点愈来愈多，而且网络速度愈来愈快，如今架构又在从新向计算和存储分离这一方向从新开始发展。

4.谁在使用计算和存储分离

上面咱们讲了不少理论相关的知识，相信你们已经对“计算和存储分离”已经有必定的认识了,那么其到底在哪些地方作了使用呢？其影响比较大的有两块，一个是数据库，另一个是消息队列，接下来我会具体讲下这两块究竟是怎么利用“计算和存储分离”的。

4.1 数据库

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

能够看见咱们的master接收数据的变动，咱们的从数据库读取binlog信息，重放binlog从而达到数据复制。 在Mysql的主从架构中有不少问题：

• 主库的写入压力比较大的时候，主从复制的延迟会变得比较高，因为咱们其复制的是binlog，他会走完全部的事务。
• 增长从节点速度慢，因为咱们须要将数据全量的复制到从节点，若是主节点此时存量的数据已经不少，那么扩展一个从节点速度就会很慢高。
• 对于数据量比较大的数据库，备份的速度很慢。
• 成本变高，若是咱们的数据库的容量比较大，那么咱们相应的全部从节点的容量都须要和猪数据库同样大,咱们的成本将会随着咱们所须要从数据库的数量进行线性增长。

这一切的问题好像都在指引着咱们走向计算和存储分离的道路，让全部的节点都共享一个存储。在2014年，在AWS大会上，AWS就宣布推出Aurora。这是一个面向亚马逊关系数据库服务（RDS）的兼容MySQL的数据库引擎，Aurora完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求。目前的Aurora可跨3个可用区的6-路复制、30秒内即可完成故障转移、同时具有快速的crash recovery能力。在性能方面，Aurora如今比RDS MySQL5.6和5.7版本快5倍。

Aurora将MySQL存储层变为为独立的存储节点,在Aurora中认为日志即数据，将日志完全从Mysql计算节点中抽离出来，都由存储节点进行保存，而且也取消了undolog用于减少计算存储之间的交互和传输数据带宽。

一样的在阿里的团队中，也借鉴了Aurora的思想，并在其上面作了不少优化，因为Aurora对于Mysql-Innodb的存储引擎修改较大，后续的Mysql的更新，必然成本很大，因此阿里的团队在保有了原有的MySQL IO路径的基础之上推出了PolarDB。其设计架构图以下：

这里咱们须要关注下面几个东西：

• libfis:这是一个文件系统库，提供了供计算节点访问底层存储的API接口，进行文件读写和元数据更新等操做，有了这个以后计算节点就不须要关心存储的数据到底在哪。
• ChunkServer能够认为是一个独立的存储子节点，每一个ChunkServer管理着一块SSD硬盘，多个ChunkServer组成Polardb存储节点，对于计算节点来讲只须要认为其是一个大的存储节点就好。
• PolarSwitch：是部署在计算节点的Daemon，它负责接收libpfs发送而来的文件IO请求，PolarSwitch将其划分为对应的一到多个Chunk，并将请求发往Chunk所属的ChunkServer完成访问。

固然PolarDB还有不少其余的细节，你们有兴趣能够阅读阿里云的官方文档，经过这种共享存储的方式，咱们就能够根据本身的业务来进行不一样的配置申请，好比咱们的对并发要求不高，对数据量要求很大，那么咱们就能够申请大量的存储空间，计算资源相对来讲就能够较小，若是咱们对并发要求很高，尤为是读请求，那么咱们就能够申请多台读机器直到知足咱们要求为止。

其实不止是这些，如今不少的数据库都在逐渐向“计算和存储分离”靠拢，包括如今的OceanBase ，TiDB等等。因此“计算和存储分离”应该是将来数据库的主要发展方向。

4.2 消息队列

我在以前写过不少关于消息队列的文章，有Kafka的，也有RocketMQ的，不管是Kafka仍是RocketMQ其设计思想都是利用本地机器的磁盘来进行保存消息队列，这样实际上是由必定的弊端的：

• 数据有限，使用者两个消息队列的同窗应该深有感触，通常会服务器保存最近几天的消息，这样的目的是节约存储空间，可是就会致使咱们要追溯一些历史数据的时候就会致使没法查询。
• 扩展成本高，在数据库中的弊端在这里一样也会展示。

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

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

• 数据计算也就是Broker，其做用和Kafka的Broker相似，用于负载均衡，处理consumer和producer等，若是业务上consumer和producer特别的多，咱们能够单独扩展这一层。
• 数据存储也就是Bookie，pulsar使用了Apache Bookkeeper存储系统，并无过多的关心存储细节，这一点其实咱们也能够借鉴参考，当设计这样的一个系统的时候，计算服务的细节咱们须要本身多去思考设计，而存储系统可使用比较成熟的开源方案。

Pulsar理论上来讲存储是无限的，咱们的消息能够永久保存，有人会说难道硬盘不要钱吗？固然不是咱们依然要钱，在Pulsar能够进行分层存储，咱们将旧的消息移到便宜的存储方案中，好比AWS的s3存储，而咱们当前最新的消息依然在咱们比较贵的SSD上。在这个模式下不只是存储是无限，咱们的计算资源扩展也是无限的，由于咱们的计算资源基本上是无状态的，扩展是没有任何成本的，因此Pulsar也搞出了一个多租户的功能,而不用每一个团队单独去创建一个集群，以前在美团的确也是这样的，比较重要的BG基本上都有本身的Mafka集群，防止互相影响。

Kafka最新的一些提议，也在向这些方面靠拢，好比也在讨论是否支持分层存储，固然是否采用“计算和存储分离”架构这个也是不必定的，可是我认为“计算和存储分离”的方向也是消息队列将来发展的主要方向。

总结

“计算和存储分离”随着云原生的发展，在各类系统中出现的次数愈来愈多，但愿你们读完这篇文章能对其有个简单的认识。同时若是你们将来在设计系统的时候，这个方案也能够做为选择方案之一进行考虑。

若是你们以为这篇文章对你有帮助，你的关注和转发是对我最大的支持，O(∩_∩)O: