RAMCloud：記憶體雲端儲存的記憶體配置機制

現在全快閃記憶體陣列已經見怪不怪了，EMC的XtremIO，還有VNX- F（Rockies），IBM FlashSystem。全快閃記憶體真正為效率而生，重新定義儲存速度。憑藉極致效能，高可用性，為您極大提高企業級應用效率。提到快閃記憶體的優勢，那麼毋庸置疑的就是速度！而在速度優勢背後，SSD則面臨著價格、容量以及壽命等方面的限制。

當然隨著技術的發展，成本的下降，SSD有可能會取代機械硬碟，成為下一代企業儲存區的主要介質。機械硬碟可能轉變為磁帶的角色。

但是，快閃記憶體速度的確就是現在儲存系統的極限嗎？現在有需要基於記憶體的資料庫，比如Redis，TimesTen。也不得不提緩衝系統的極佳實踐 memcached。spark也把操作的中間資料全都放入到記憶體中，避免了Hadoop即時性和可用性差的問題，有可能對Hadoop的生態圈產生深遠影響。spark已經於2014年2月27日正式成為Apache基金會的頂級項目了。

RAMCloud，是一個完全使用DRAM的儲存系統，它的所有資料都儲存到記憶體中。當然了為了故障恢複RAMCloud會將日誌和資料的備份持久化到普通硬碟中。在2014年的FAST會議中，RAMCloud發表了關於記憶體配置及管理機制的paper，並且被評為best paper，拜讀此文後，形成此文以分享心得。

1. Why not use malloc?

現在又很多memory allocator，比如C的malloc，Google的tcmalloc。當然了還有Java的記憶體管理及GC。但是它們有幾個問題，一個是效率底下，在訪問模式變化多端時極容易產生記憶體片段。實驗表明，使用malloc只能使記憶體的利用率最大到50%。

memory allocator可以分成兩類：non-copying and copying。non-copying allocator就是在記憶體配置後不會再移動它。對於單一的程式來說，這種分配方式非常自然，因為畢竟這些記憶體一旦申請它的大小也基本上不會再變了。但是對於儲存系統來說，檔案可以修改，比如增大或者減小，那麼如果使用malloc，需要重新申請新的記憶體塊，那麼就非常容易產生片段。比如系統剛開始建立了一片100B大小的檔案，後來部分檔案增大到130B，那麼，釋放的100B的空間有可能會產生片段，比如以後沒有再寫<=100B大小的檔案。（註：記憶體片段的確在這種記憶體儲存系統中非常容易產生，而且作者設計的測試案例的確也使得malloc的記憶體利用率最大也就到50%。但是實際生產環境是否是這個樣子現在不得而知。總之RAMCloud的記憶體配置和管理的確挺好，但是malloc是否在生產環境下是否是真的如此不堪，現在也無法定論。關於 malloc的記憶體配置，請閱《malloc記憶體配置與free記憶體釋放的原理》）。

對於copying allocator，通過garbage collector的確可以解決片段的問題。但是缺點就是需要遍曆所有的資料才能夠重新分配。但是，處於效能的考慮，需要很多額外的記憶體（1.5倍到5 倍）。這樣也就失去了通過片段管理來提高記憶體使用量率的初衷了。而且還有一個問題是需要長時間的服務暫停。拿Java的GC來說，它需要3-4秒，這個時間對於RAMCloud來說，已經可以檢測到一個故障的節點並且恢複64GB的資料了。（注: 不知道是否是不恰當的使用Java使得在此蒙冤了，儘管的確它是有問題）

2. RAMCloud概述

由於本文主要為了闡述基於日誌的記憶體配置管理，因此本節主要介紹storage的management，和為什麼需要基於日誌的記憶體配置管理機制，而摒棄原有的。

RAMCloud最適合的情境是已經將伺服器分為應用伺服器（主要實現產生網頁和執行商務規則等應用邏輯）和儲存伺服器（為應用伺服器提供長期共用儲存）的資料中心。這些資料中心一般支援許多應用，有的很小，只使用一台伺服器的一部分能力，有的很大，要用到數千台專用應用和儲存伺服器。

而且，記憶體雲中儲存的資訊必須和硬碟一樣持久，單個儲存伺服器的故障不能造成資料丟失和哪怕幾秒鐘的服務不可用。RAMCloud將所有資料存放在 DRAM中，效能可以達到比目前最高效能的硬碟儲存系統還要高100～1000倍。在訪問延遲方面，RAMCloud方案中運行在應用伺服器中的一個進程從同一資料中心的儲存伺服器中通過網路讀取數百位元組資料只需5～10μs，而目前實際系統一般要花費0.5～10ms，具體取決於資料是在伺服器記憶體緩衝中，還是硬碟中。而且，一台多核儲存伺服器每秒可以服務至少100萬次小讀取請求。而硬碟系統中同樣的機器每秒只能服務1000～10000次請求。

系統架構圖如下。