聊聊計算和存儲分離

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: