在上一篇文章中，作者着重介紹了分佈式塊存儲的相關背景和元數據服務。本文中，作者將主要介紹存儲引擎相關的技術與實現。
我們還是先來看一下我們會對數據存儲引擎模塊有什麼樣的需求。
首先，肯定是還是可靠。因爲我們客戶的應用場景都大部分是核心的應用，數據可靠是要絕對保證的，沒有任何妥協的空間。
其次是性能，目前在萬兆網絡和 SSD，包括 NVMe SSD 都已經非常普及。隨着硬件的速度越來越快，性能的瓶頸會從硬件轉移到軟件。尤其對於存儲引擎來說，性能至關重要。
除了追求絕對的性能以外，我們還希望能夠做到高效。我們希望每一個 CPU 指令都不被浪費。我們追求用最少的 CPU 指令完成一次 IO 操作。這背後的原因是，存儲硬件設備越來越快，目前最快的存儲已經可以做到單次訪問只需要 10 納秒。而如果程序中加一次鎖，做一次上下文切換，可能幾百個納秒就過去了。如果不做到高效的話，目前的 CPU 可能完全無法發揮出 SSD 的性能。除了高效的使用 CPU 以外，我們也要高效的使用內存資源，網絡帶寬資源。同時，由於目前相同容量的 SSD 的價格還高於 HDD 的價格，所以我們也儘可能的節省磁盤空間的佔用，通過利用壓縮，去重等技術，提高 SSD 的空間使用效率。
最後，也是非常重要的一點，存儲引擎需要易於 Debug，而且要易於升級。對於軟件工程師來說，50% 以上的工作時間都是在做 Debug，而對存儲軟件工程師來說，這個比例可能更高。我們希望做一個非常易於 Debug 的軟件產品，如果發現問題，可以快速的定位並修復。升級也是一樣，現在軟件的迭代速度越來越快，我們希望軟件可以方便的易於升級，這樣我們可以讓用戶更快的使用上新版本的軟件，享受到新版本的功能，以及性能的優化。
接下來，我們來看一下具體的實現。很多傳統的存儲廠商在實現存儲引擎的時候，往往會選擇把整個 IO 路徑的實現放在 Kernel Space 裏面。例如在上圖中，上層是一個核心的存儲引擎，下層是文件系統，塊設備，以及驅動。由於網絡棧也是實現在內核中的，把存儲引擎放在內核裏面就可以最大化性能，減少上下文切換（Context Switch）。但這種實現有很多非常嚴重的問題，首先就是難於 Debug。如果大家做過內核開發，就會知道在內核中 Debug 是一件非常麻煩的事情。而且開發語言也只能用 C，不能用其他語言。
同時，在內核裏面開發，升級會非常困難。一次升級，不管是 Bugfix，還是增加新功能，都可能需要重啓整個服務器，這對於存儲系統來說代價是非常巨大的。還有一個很重要的因素就是故障域非常大。Kernel 裏面的模塊如果出問題，可能導致整個 Kernel 被污染，可能是死鎖，可能是 Kernel Panic。通常也是需要重啓服務器才能修復。
既然有這麼多問題，那我們在設計的時候肯定不會選擇用 Kernel Space 的方式。我們選擇在 Userspace，也就是用戶態實現我們的存儲引擎。
在 User Space 實現，很多項目會選擇把存儲引擎構建在 LSM Tree 的數據結構上。LSM Tree 運行在文件系統之上。User Space 和 Kernel 比起來更靈活，可以用各種語言；升級也很方便，只需要重啓一下進程就可以，不需要重啓服務器；User Space 的故障只會影響到服務進程本身，並不會影響到 Kernel 的運行。但這種方式的問題就是性能不夠好，由於 IO 還是需要經過 Kernel，所以會產生上下文切換，這個切換就會引入性能的開銷。
接下來，我們來說一下 LSM Tree。LSM Tree 的數據結構以及實現我們在這裏就做不詳細介紹了。總的來說，LSM Tree 是很多存儲引擎的核心。
LSM Tree 的好處就是實現起來是相對簡單的，有很多開源的實現可以參考，而且它對小塊數據寫入優化做的非常好，會將小塊數據合併，並批量寫入。
然而 LSM Tree 並不是銀彈，它最大的問題由於他的數據結構而導致的『讀放大』和『寫放大』。這個問題會有多嚴重呢。我們可以來看一下這個圖，這是一個對『讀寫放大』的測試結果。從圖中可以看到，如果寫入 1GB 的數據，最終會產生 3 倍的數據寫入量，也就是 3 倍的『寫放大』。如果寫入 100G 的話，則會被放大到 14 倍，也就是說如果寫 100G 的數據，實際上在磁盤上會產生 1.4TB 的寫流量。而『讀放大』會更加嚴重，在這個場景下會放大到 300 多倍。這就違背了我們最開始提到了我們希望提高硬件效率的訴求。
LSM Tree 雖然有各種各樣的好處，但是由於存在嚴重的『讀寫放大』問題，所以我們並不會採用LSM Tree 來做數據存儲引擎。我們可以借鑑 LSM Tree 中優秀的思想，結合我們自己的需求，實現一套存儲引擎。這個包含了數據分配，空間管理，IO 等邏輯。
接下來，我們看到這個這個圖中還有一個文件系統。這個文件系統是實現在內核中的，在塊設備之上。大家比較常見的文件系統包括 ext4，xfs，btrfs 等，很多存儲引擎也是實現在文件系統之上的。然而我們需要思考一下我們是否真的需要一個文件系統。
首先，文件系統所提供的功能遠遠多於存儲引擎的需求。例如文件系統提供的 ACL 功能，Attribute 功能，多級目錄樹功能，這些功能對於一個專用的存儲引擎來說，都是不需要的。這些額外的功能經常會產生一些 Performance Overhead，尤其是一些全局鎖，對性能影響非常嚴重。
其次，大部分文件系統在設計的時候，都是面向單一磁盤的設計方式，而不是面向多塊磁盤的。而一般存儲服務器上都會部署 10 塊，甚至更多的磁盤，而且有可能是 SSD，有可能是 HDD，也可能是混合部署。
第三，很多文件系統在異步 IO 上支持的並不好，儘管支持異步 IO 的接口，但實際使用過程中，偶爾還是會有阻塞的情況發生，這也是文件系統裏一個非常不好的地方。
最後一個問題，文件系統爲了保證數據和元數據的一致性，也會有 Journaling 的設計。但這些 Journaling 也會引入寫放大的問題。如果服務器上掛載了多個文件系統，單個文件系統的 Journaling 也無法做到跨文件系統的原子性。
最終我們在設計存儲引擎的時候，我們選擇了拋棄文件系統，拋棄 LSM Tree，自己在做一個理想中的存儲引擎，去掉不必要的功能，儘可能的避免寫放大。把我們想要的功能直接實現在塊設備上。
我們並沒有想要自己實現 Block Layer 這一層，這是因爲 Linux Kernel 中，Block Layer 是非常薄的一層，裏面實現的算法也非常簡單，這些算法也都有參數可調，也都有辦法關閉掉，所以不會有太多額外的性能開銷。
左邊這個圖就是 ZBS 目前的實現方式。但這種方式最大的問題還是性能，Block Layer 和 Driver 都運行在 Kernel Space，User Space 的存儲引擎的 IO 都會經過 Kernel Space，會產生 Context Switch。未來我們會轉向右邊這個圖的方式，通過 SSD 廠家提供的 User Space 驅動，結合 PMD（Poll Mode Driver）引擎，以提供更好的性能。
接下來，我們看一下 ZBS 的 User Space 存儲引擎具體的實現。
IO Scheduler 負責接收上層發下來的 IO 請求，構建成一個 Transaction，並提交給指定的 IO Worker。IO Worker 負責執行這個 Transaction。Journal 模塊負責將 Transaction 持久化到磁盤上，並負責 Journal 的回收。Performance Tier 和 Capacity Tire 分別負責管理磁盤上的空閒空間，以及把數據持久化到對應的磁盤上。
作者簡介
張凱，畢業於清華計算機系，畢業以後加入百度基礎架構部工作了兩年，主要從事分佈式系統和大數據相關的工作。張凱也是開源社區的代碼貢獻者，參與的項目包括 Sheepdog 和 InfluxDB。其中 Sheepdog 是一個開源的分佈式塊存儲項目，InfluxDB 是一個時序數據庫（Time Series Database，TSDB）項目。2013 年張凱從百度離職，和清華的兩個師兄一起創辦了 SmartX 公司。