[[330987]]

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

 1.背景

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

2.何為計(jì)算?何為存儲(chǔ)?

要了解計(jì)算和存儲(chǔ)分離到底是什么，那么我們就需要理解什么是計(jì)算，什么是存儲(chǔ)。

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

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

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

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

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

3.為何需要計(jì)算和存儲(chǔ)分離

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

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

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

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

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

4.誰在使用計(jì)算和存儲(chǔ)分離

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 消息隊(duì)列

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

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

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

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

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

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

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

總結(jié)

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