2018年12月12日，2018中國存儲與數據峰會的閃存存儲與應用論壇上，阿里巴巴資深技術專家石超介紹了阿里巴巴在分布式存儲方面的技術積累，一方面服務于阿里巴巴自己的電商業務，一方面以阿里云的方式向外界提供服務。

阿里巴巴做存儲可能跟其他公司不太一樣，我們真的做了一個存儲平臺，把各個業務統一起來，然后用同一套系統去支持這個業務。十年前我們開始做這個系統，隨后在2010年、2011年我們基于盤古系統發布了公有云的產品，像大數據的ODPS、ECS，還有我們的對象存儲OSS服務。

在2013年有一個關鍵事件——阿里巴巴的飛天5K項目落成。同一時代在阿里內部還有其他的存儲系統在用，還有云梯1和云梯2系統，2013年把這兩個系統合并了，這是離線大數據上的標志性事件。2016年，盤古2.0項目啟動等等。

阿里巴巴可能和其他做云產品的公司不一樣，對于我們來說，我們做這些新的技術，并不是讓大家去做小白鼠，阿里巴巴自己內部關鍵的電商業務也是跑在同一套系統上。

比如電商交易的核心系統，比如雙11和雙12，大家在淘寶上下單，淘寶的數據庫、消息界面系統，都是由同一套系統來支撐的。我們的主力云產品包括ECS和OSS的存儲，也都是在我們的系統上。對于統一存儲，我覺得有幾個關鍵的業務特點：

第一，我們的規模非常大，應該說阿里集團大部分的數據都在這個系統上。

第二，我們支持了非常核心的系統，內部系統會和外部系統業務稍微有一些區別。

一方面，比如我們的業務系統的分布式架構做的很好，因為它要面對雙11的沖擊，所以，要求系統能夠在短時間內承受非常高的流量沖擊，需要你的系統有非常好的彈性。

一方面，云產品又稍微有點不一樣，云產品面對的是很多架構上沒有那么好的公司，比如創業公司，他們的架構比較簡單，但是對我們單個存儲或者單個OSS的可用性要求非常高，所以這兩個需求又有點不一樣。

同時受到這兩方面的驅動，我們做統一的存儲，用統一的技術服務這兩種類型的應用。

為什么我們去用分布式存儲解決這些問題？

我講一個實踐例子，講一個今年我們用存儲技術支持雙11大促的例子。

上圖，今年雙11零點高峰期，數據庫對于分布式存儲的讀寫的圖，我們可以看到零點是一個標志，到了0點之后流量開始上來了，到了0點30分流量開始下跌，是和之前差不多的情況。

所以，電商面臨這樣一個場景，我們到底要準備多少臺機器去撐這個高峰，如果我們準備了很多機器去滿足這個流量，那么這個流量只持續個把小時，那么這就是一種浪費。

所以，阿里在這兩三年一直在做一個叫做混部的技術，具體來說我們有很多應用服務器是跑在線的業務，有另一些應用服務器跑離線的業務。一般公司的做法都是在線業務比如數據庫、Web服務器都是延時敏感的業務，不能和離線業務放在一起。但是在阿里來說，面對電商雙11我們需要一個非常有彈性的系統，這兩年為了應對雙11，我們能夠把離線業務的機器讓出來，讓它去跑在線應用，等雙11這個高峰過去之后在線的應用可以縮回來，讓離線的業務利用在線的機器完成自己的工程。

這樣一件事有很多挑戰，對于存儲來說意味著什么？挑戰在哪里？

我覺得有兩點：一個是在線應用和離線應用對于存儲要求完全不一樣。在線應用現在SSD可以做到幾十微秒的延遲，離線應用只要吞吐大、容量大就好。

有一些應用是沒有狀態的，比如跑一個Web服務器，它在本地存儲的數據就是它的程序文件，運行時它可能有一些文件緩存，程序運行起來可能會打日志，這些東西都是當程序從一個機器遷到另一臺機器做擴展時可以丟掉的，是可以重新從遠程拉起來的。

另一些程序是有狀態的，比如說數據庫，數據庫在本地有它的數據，消息隊列有它的數據文件，如果要做擴展，你需要把這個數據遷移到另一臺機器，過程很耗時，并且沒有什么彈性，你需要事先準備很長時間。這兩點使得我們在做混部時，對存儲提出了很大挑戰。

怎么解決這個問題呢？

我們有一個概念叫做存儲和計算分離。老話說30年河西30年河東，以前用企業存儲天然就是存儲和計算分離，現在我們又回到了這樣一個架構。我們的在線服務器也不去寫本地的盤，單獨搭一個存儲的機器，把這些機器分成存儲和計算兩種，存儲專門放數據，上面不跑業務。計算上面跑業務，用計算節點的CPU資源、內存，但是它不去寫本地的盤。這樣高峰到來，我們很輕松地把一些計算任務從一個計算的節點去彈性彈到離線的服務器上，峰值過去之后再縮回來。

有了存儲和計算分離后，數據就不用寫本地盤了，而是寫到遠程分布式存儲，這對于分布式存儲來說不太容易做到，但還好，隨著業界技術的進步，我們有了高性能的網絡和閃存，分布式存儲在一些方面上做的并不比本地的盤差，甚至在某些方面做的更好。

具體在哪些地方比較好呢？

首先，可靠性來說，分布式存儲天然就在做機器之間的冗余，可以打造更好的可靠性。

從性能來說，我們用了一些比較新的技術，用戶態的一些技術，能夠使分布式存儲和本地的盤達到差不多的水平，同時，因為分布式存儲后臺是一個大的資源池，對于特定的應用，比如說當IO集中在一塊盤上或者幾塊盤上，小部分的盤的時候，可以利用更多的機器來完成這個。在這種場景下，會比本地的盤更好。

成本方面也有彈性，當你去用本地盤的時候，你會面臨容量規劃的問題，可能1%的情況下，某個程序有問題把盤用滿了，可能會引起整個系統的崩潰。在分布式存儲的情況下，它是一個資源池，容量規劃的時候更簡單。可以把不同用戶的盤，放在一個大的池子里，這樣一來，空閑的空間就會比較少。

我挑幾點詳細介紹一下。

第一點，當我們做大規模糾刪碼的實踐，在傳統存儲對應的就是做Raid的糾刪碼，但是Raid給人的印象是，這個東西比較慢，恢復的比較慢，恢復的過程會有損等等。當你把這個問題放在跨機器的集群很多事會變得比較好辦。我們可以跨機器去做糾刪碼，我們可以跨網絡交換機做糾刪碼，甚至跨可用區做糾刪碼。我們會找一個城市，找三個地方，在三個地方之間搭機房，用比較快的網絡。可以把一部分數據做糾刪碼，分在三個地方。

做糾刪碼的時候可以用更多的數據塊等等把這個做的更安全。我們線上基本采用的都是N+3，任何三塊盤死機我都不損失數據。同時因為池子變大了，所以，我們是在幾百、幾千臺機器的規模上去做糾刪碼。當你一個節點死機的時候，我會有成百上千的機器做恢復，所以，可以解決傳統陣列恢復時間慢、有損的問題。

下面講分布式存儲的可靠性給業務帶來什么。

我們知道，在阿里自己的業務和云不太一樣，阿里自己的電商業務本身就是分布式的，是一個多地域、分布式的很多小應用組成的系統。為什么這個時候還需要做存儲的分布式？以數據庫為例，數據庫非常有代表性，很多人首先覺得做分布式數據庫很難，基于MySQL做存儲計算分離也不太容易。

阿里在很多年之前就開始了去IOE進程，去IOE之后就走向了MySQL分庫、分表的架構上。為什么做分庫分表？這因為MySQL單機的性能是受限的，隨著業務的增長必須用多臺機器去做，與此同時，為了解決單機的可靠性、可用性的問題，MySQL還去做主備，當主死機以后可以馬上切備庫。同時在MySQL用本地盤的時候，還會給盤做Raid，進一步增加盤的可靠性。轉到分布式存儲之后，其實它解決的是數據可靠性問題，但是并沒有解決業務的可用性問題。

在業務層和存儲層，大家各司其職去擴展。存儲層專注于解決數據本身的高可靠、高可用問題。而MySQL應用層，專注解決事物處理、擴展一致性的問題。

通常認為分布式存儲是要走網絡，傳統本地存儲是直接用PCIe這樣的高速連接去連到存儲，分布式存儲然的弱點就是接入網絡，分布式存儲因為數據要寫多份，要跨故障率去寫多份，網絡的鏈路就會更長。

得益于現在用戶態技術的發展，前面雖然分布式存儲有很多好處，但是性能是一個硬的限制，一旦性能滿足不了要求，前面各種優勢，在業務方面都沒有體現。

具體來說，我們用用戶的軟件棧做的事情就是采用Run-to-Completion的線程模型，這個過程中單機內部沒有線程切換，沒有鎖、沒有口，我們把這些東西都去掉了，能夠達到非常好的性能。

同時因為分布式存儲自身的特點，它是基于這些不穩定的硬件搭建出一個穩定的系統。