[[330987]]

本文轉(zhuǎn)載自微信公眾號「咖啡拿鐵」，作者咖啡拿鐵 。轉(zhuǎn)載本文請聯(lián)系 咖啡拿鐵公眾號。

 1.背景

這篇文章是我一直想寫的一篇，因?yàn)?ldquo;計算和存儲分離”最近幾年在大家的視野中出現(xiàn)得越來越多，但其實(shí)很多對于其到底代表著什么也是模糊不清，這里我查閱了很多的資料再結(jié)合平時自己的理解，聊聊到底什么是“計算和存儲分離”

2.何為計算?何為存儲?

要了解計算和存儲分離到底是什么，那么我們就需要理解什么是計算，什么是存儲。

計算這個單詞有運(yùn)算之義，和數(shù)學(xué)的關(guān)系密不可分。大家回想一下以前數(shù)學(xué)考試的時候，那一道道的數(shù)學(xué)題怎么得出結(jié)果的，這一過程其實(shí)稱之為計算。那我們這里談?wù)摰钠鋵?shí)是計算機(jī)計算，所以我們可以得出通過計算機(jī)得到問題的結(jié)果這個就叫做計算機(jī)計算，也就是我們這里所談?wù)摰?quot;計算"。

對于存儲來說，這個概念比較難以定義，很多人都簡單的認(rèn)為這個是硬盤，U盤等。但其實(shí)在我們的計算機(jī)計算過程中和存儲是密不可分的，我們知道CPU是由控制器、運(yùn)算器和寄存器組成的，我們在運(yùn)行一段程序的時候我們的指令是存儲在我們的存儲器的，我們所執(zhí)行的每一個步驟都和存儲分離不開。比如我們以前考試的時候選擇題，大家關(guān)心的只是你選擇是否正確，不會關(guān)心你的運(yùn)算過程，你的運(yùn)算結(jié)果可以看做是硬盤，需要持久化給評卷人看，而你的計算過程類似草稿紙，雖然不需要給評卷人看，但是一樣的是實(shí)實(shí)在在的寫在了紙上。

上面我們說了在計算機(jī)中計算和存儲其實(shí)是分離不開的，我們想想如果將計算和存儲分離開來，通過高速網(wǎng)絡(luò)進(jìn)行交互，那么我們的CPU的每一條指令都需要通過網(wǎng)絡(luò)傳輸，而我們的網(wǎng)絡(luò)傳輸和我們當(dāng)前的CPU速度完全不匹配，所以我們的計算和存儲分離其實(shí)是一個偽需求，當(dāng)然在未來的某一天如果我們的網(wǎng)絡(luò)傳輸?shù)臅r間可以忽略不計，計算和存儲分離也就能真正的實(shí)現(xiàn)了。

計算和存儲分離既然是一個偽需求，那為什么這么多人還在提及呢?那就需要重新再定義一下他們的含義，我們將計算過程中的存儲歸納為計算，只關(guān)注問題和結(jié)果，這就是我們新的“存儲”的定義，就類似我們考試的時候草稿紙不需要存放，可以任意撕毀一樣。

那這里我們來做一個最終的定義，我們后面所講的“存儲”都是需要持久化的，可以是U盤，硬盤，網(wǎng)盤等等，我們所講的“計算”其實(shí)就是我們的計算過程所需要的CPU和內(nèi)存等。

3.為何需要計算和存儲分離

計算和存儲分離并不是現(xiàn)在才出現(xiàn)的一個新名詞，在20年前就有NAS-網(wǎng)絡(luò)附加存儲這個東西，本質(zhì)上也就是使用TCP/IP協(xié)議的以太網(wǎng)文件服務(wù)器。當(dāng)時如果想要大規(guī)模的存儲，就會讓服務(wù)器將數(shù)據(jù)保存到NAS這個上面，但是NAS價格及其昂貴，并且擴(kuò)展比較困難，NAS也就不適用于高速發(fā)展的互聯(lián)網(wǎng)應(yīng)用。

這個時候谷歌摒棄了之前的觀念“移動存儲到計算”，采取了“移動計算到存儲的觀念”，將計算和存儲耦合了，因?yàn)楫?dāng)時的網(wǎng)絡(luò)速度對比現(xiàn)在來說慢了幾百倍，網(wǎng)絡(luò)速度跟不上我們的需要。在在典型的MapReduce部署中計算和存儲都在同一個集群中進(jìn)行，比如后續(xù)的hadoop。這里其實(shí)也就是用本地IO速度來替換網(wǎng)絡(luò)傳輸速度。

隨著技術(shù)的進(jìn)步，我們的網(wǎng)絡(luò)速度也越來越快，我們的瓶頸不再是網(wǎng)絡(luò)速度，但是我們的磁盤I/O速度卻沒有明顯的速度增長，計算和存儲融合的架構(gòu)缺點(diǎn)也再逐漸暴露：

• 機(jī)器的浪費(fèi)：業(yè)務(wù)是計算先達(dá)到瓶頸的，還是存儲先達(dá)到瓶頸的。這兩種情況往往是不一樣的，往往時間點(diǎn)也是不一樣的。在架構(gòu)里就存在一定的浪費(fèi)。如果說計算不夠，也是加一臺機(jī)器;存儲不夠，還是加一臺機(jī)器。所以這里就會存在很多浪費(fèi)。
• 機(jī)器配比需要頻繁更新：一般來說在一個公司內(nèi)機(jī)器的配型比較固定比如提供好幾種多少核，多少內(nèi)存，多少存儲空間等等。但是由于業(yè)務(wù)在不斷的發(fā)展，那么我們的機(jī)器配型也需要不斷的更新。
• 擴(kuò)展不容易：如果我們存儲不夠了通常需要擴(kuò)展，計算和存儲耦合的模式下如果擴(kuò)展就需要存在遷移大量數(shù)據(jù)。

由于計算和存儲耦合的缺點(diǎn)越來越多，并且網(wǎng)絡(luò)速度越來越快，現(xiàn)在架構(gòu)又在重新向計算和存儲分離這一方向重新開始發(fā)展。

4.誰在使用計算和存儲分離

上面我們講了很多理論相關(guān)的知識，相信大家已經(jīng)對“計算和存儲分離”已經(jīng)有一定的認(rèn)識了,那么其到底在哪些地方做了使用呢?其影響比較大的有兩塊，一個是數(shù)據(jù)庫，另外一個是消息隊列，接下來我會具體講下這兩塊到底是怎么利用“計算和存儲分離”的。

4.1 數(shù)據(jù)庫

一談到數(shù)據(jù)庫我們不得不想到MySql,這個應(yīng)該也是大家最熟悉的數(shù)據(jù)庫，下面是Mysql的一個主從架構(gòu)圖：

可以看見我們的master接收數(shù)據(jù)的變更，我們的從數(shù)據(jù)庫讀取binlog信息，重放binlog從而達(dá)到數(shù)據(jù)復(fù)制。

在Mysql的主從架構(gòu)中有很多問題：

• 主庫的寫入壓力比較大的時候，主從復(fù)制的延遲會變得比較高，由于我們其復(fù)制的是binlog，他會走完所有的事務(wù)。
• 增加從節(jié)點(diǎn)速度慢，由于我們需要將數(shù)據(jù)全量的復(fù)制到從節(jié)點(diǎn)，如果主節(jié)點(diǎn)此時存量的數(shù)據(jù)已經(jīng)很多，那么擴(kuò)展一個從節(jié)點(diǎn)速度就會很慢高。
• 對于數(shù)據(jù)量比較大的數(shù)據(jù)庫，備份的速度很慢。
• 成本變高，如果我們的數(shù)據(jù)庫的容量比較大，那么我們相應(yīng)的所有從節(jié)點(diǎn)的容量都需要和豬數(shù)據(jù)庫一樣大,我們的成本將會隨著我們所需要從數(shù)據(jù)庫的數(shù)量進(jìn)行線性增加。

這一切的問題好像都在指引著我們走向計算和存儲分離的道路，讓所有的節(jié)點(diǎn)都共享一個存儲。在2014年，在AWS大會上，AWS就宣布推出Aurora。這是一個面向亞馬遜關(guān)系數(shù)據(jù)庫服務(wù)(RDS)的兼容MySQL的數(shù)據(jù)庫引擎，Aurora完美契合了企業(yè)級數(shù)據(jù)庫系統(tǒng)對高可用性、性能和擴(kuò)展性、云服務(wù)托管的需求。目前的Aurora可跨3個可用區(qū)的6-路復(fù)制、30秒內(nèi)便可完成故障轉(zhuǎn)移、同時具備快速的crash recovery能力。在性能方面，Aurora現(xiàn)在比RDS MySQL5.6和5.7版本快5倍。

Aurora將MySQL存儲層變?yōu)闉楠?dú)立的存儲節(jié)點(diǎn),在Aurora中認(rèn)為日志即數(shù)據(jù)，將日志徹底從Mysql計算節(jié)點(diǎn)中抽離出來，都由存儲節(jié)點(diǎn)進(jìn)行保存，并且也取消了undolog用于減小計算存儲之間的交互和傳輸數(shù)據(jù)帶寬。

同樣的在阿里的團(tuán)隊中，也借鑒了Aurora的思想，并在其上面做了很多優(yōu)化，由于Aurora對于Mysql-Innodb的存儲引擎修改較大，后續(xù)的Mysql的更新，必然成本很大，所以阿里的團(tuán)隊在保有了原有的MySQL IO路徑的基礎(chǔ)之上推出了PolarDB。其設(shè)計架構(gòu)圖如下：

這里我們需要關(guān)注下面幾個東西：

• libfis:這是一個文件系統(tǒng)庫，提供了供計算節(jié)點(diǎn)訪問底層存儲的API接口，進(jìn)行文件讀寫和元數(shù)據(jù)更新等操作，有了這個之后計算節(jié)點(diǎn)就不需要關(guān)心存儲的數(shù)據(jù)到底在哪。
• ChunkServer可以認(rèn)為是一個獨(dú)立的存儲子節(jié)點(diǎn)，每個ChunkServer管理著一塊SSD硬盤，多個ChunkServer組成Polardb存儲節(jié)點(diǎn)，對于計算節(jié)點(diǎn)來說只需要認(rèn)為其是一個大的存儲節(jié)點(diǎn)就好。
• PolarSwitch：是部署在計算節(jié)點(diǎn)的Daemon，它負(fù)責(zé)接收libpfs發(fā)送而來的文件IO請求，PolarSwitch將其劃分為對應(yīng)的一到多個Chunk，并將請求發(fā)往Chunk所屬的ChunkServer完成訪問。

當(dāng)然PolarDB還有很多其他的細(xì)節(jié)，大家有興趣可以閱讀阿里云的官方文檔，通過這種共享存儲的方式，我們就可以根據(jù)自己的業(yè)務(wù)來進(jìn)行不同的配置申請，比如我們的對并發(fā)要求不高，對數(shù)據(jù)量要求很大，那么我們就可以申請大量的存儲空間，計算資源相對來說就可以較小，如果我們對并發(fā)要求很高，尤其是讀請求，那么我們就可以申請多臺讀機(jī)器直到滿足我們要求為止。

其實(shí)不止是這些，現(xiàn)在很多的數(shù)據(jù)庫都在逐漸向“計算和存儲分離”靠攏，包括現(xiàn)在的OceanBase，TiDB等等。所以“計算和存儲分離”應(yīng)該是未來數(shù)據(jù)庫的主要發(fā)展方向。

4.2 消息隊列

我在之前寫過很多關(guān)于消息隊列的文章，有Kafka的，也有RocketMQ的，不論是Kafka還是RocketMQ其設(shè)計思想都是利用本地機(jī)器的磁盤來進(jìn)行保存消息隊列，這樣其實(shí)是有一定的弊端的：

• 數(shù)據(jù)有限，使用者兩個消息隊列的同學(xué)應(yīng)該深有感觸，一般會服務(wù)器保存最近幾天的消息，這樣的目的是節(jié)約存儲空間，但是就會導(dǎo)致我們要追溯一些歷史數(shù)據(jù)的時候就會導(dǎo)致無法查詢。
• 擴(kuò)展成本高，在數(shù)據(jù)庫中的弊端在這里同樣也會展現(xiàn)。

針對這些問題ApachePulsar出現(xiàn)了，pulsar最初由Yahoo開發(fā)，在18年的時候一舉將kafka連續(xù)兩年InfoWorld最佳開源數(shù)據(jù)平臺獎奪了過來。

在Pulsar的架構(gòu)中，數(shù)據(jù)計算和數(shù)據(jù)存儲是單獨(dú)的兩個結(jié)構(gòu)：

• 數(shù)據(jù)計算也就是Broker，其作用和Kafka的Broker類似，用于負(fù)載均衡，處理consumer和producer等，如果業(yè)務(wù)上consumer和producer特別的多，我們可以單獨(dú)擴(kuò)展這一層。
• 數(shù)據(jù)存儲也就是Bookie，pulsar使用了Apache Bookkeeper存儲系統(tǒng)，并沒有過多的關(guān)心存儲細(xì)節(jié)，這一點(diǎn)其實(shí)我們也可以借鑒參考，當(dāng)設(shè)計這樣的一個系統(tǒng)的時候，計算服務(wù)的細(xì)節(jié)我們需要自己多去思考設(shè)計，而存儲系統(tǒng)可以使用比較成熟的開源方案。

Pulsar理論上來說存儲是無限的，我們的消息可以永久保存，有人會說難道硬盤不要錢嗎?當(dāng)然不是我們依然要錢，在Pulsar可以進(jìn)行分層存儲，我們將舊的消息移到便宜的存儲方案中，比如AWS的s3存儲，而我們當(dāng)前最新的消息依然在我們比較貴的SSD上。在這個模式下不僅是存儲是無限，我們的計算資源擴(kuò)展也是無限的，因?yàn)槲覀兊挠嬎阗Y源基本上是無狀態(tài)的，擴(kuò)展是沒有任何成本的，所以Pulsar也搞出了一個多租戶的功能,而不用每個團(tuán)隊單獨(dú)去建立一個集群，之前在美團(tuán)的確也是這樣的，比較重要的BG基本上都有自己的Mafka集群，防止互相影響。

Kafka最新的一些提議，也在向這些方面靠攏，比如也在討論是否支持分層存儲，當(dāng)然是否采用“計算和存儲分離”架構(gòu)這個也是不一定的，但是我認(rèn)為“計算和存儲分離”的方向也是消息隊列未來發(fā)展的主要方向。

總結(jié)

“計算和存儲分離”隨著云原生的發(fā)展，在各種系統(tǒng)中出現(xiàn)的次數(shù)越來越多，希望大家讀完這篇文章能對其有個簡單的認(rèn)識。同時如果大家未來在設(shè)計系統(tǒng)的時候，這個方案也可以作為選擇方案之一進(jìn)行考慮。