不知具體從何時起「計算和存儲分離」常常出現在討論中。要了解計算和存儲分離到底是什麼，那麼我們就需要先理解什麼是計算，什麼是存儲。

計算這個單詞有運算之義，和數學的關係密不可分。大家回想一下以前數學考試的時候，那一道道的數學題怎麼得出結果的，這一過程其實稱之為計算。那我們這裡談論的其實是計算機計算，所以我們可以得出通過計算機得到問題的結果這個就叫做計算機計算，也就是我們這裡所談論的”計算”。

對於存儲來說，這個概念比較難以定義，很多人都簡單的認為這個是硬碟，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最新的一些提議，也在向這些方面靠攏，比如也在討論是否支持分層存儲，當然是否採用「計算和存儲分離」架構這個也是不一定的，但是「計算和存儲分離」的方向也應該是消息隊列未來發展的主要方向。

隨著雲原生的發展「計算和存儲分離」，在各種系統中出現的次數越來越多，希望大家讀完這篇文章能對其有個簡單的認識。