作者介紹：
徐祥曦，七牛雲工程師，獨立開發了多套高效能糾刪碼/再生碼編碼引擎。
柳青，華中科技大學博士，研究方向為基於糾刪碼的分散式儲存系統。
前言：
隨著資料的儲存呈現出集中化（以分散式儲存系統為基礎的雲端儲存系統）和移動化（網際網路移動終端）的趨勢，資料可靠性愈發引起大家的重視。叢集所承載的資料量大大上升，但儲存介質本身的可靠性進步卻很小，這要求我們必須以更加經濟有效的方式來保障資料安全。
副本與糾刪碼都是通過增加冗餘資料的方式來保證資料在發生部分丟失時，原始資料不發生丟失。但相較於副本，糾刪碼能以低得多的儲存空間代價獲得相似的可靠性。比如 3 副本下，儲存開銷為 3，因為同樣的資料被儲存了三份，而在 10+3（將原始資料分為 10 份，計算 3 份冗餘）的糾刪碼策略下，儲存開銷為為 1.3。採用糾刪碼能夠極大地減少儲存系統的儲存開銷，減少硬體、運維和管理成本，正是這樣巨大的收益驅使各大公司紛紛將糾刪碼應用於自己的儲存系統，比如 Google、Facebook、Azure、EMC 等等國際巨頭，在國內以淘寶、華為、七牛雲等為代表的公司也在自己的儲存系統上應用了糾刪碼。
最典型的糾刪碼演算法是裡德-所羅門碼（Reed-Solomon 碼，簡稱 RS 碼）。RS 碼最早應用於通訊領域，經過數十年的發展，其在儲存系統中得到廣泛應用，比如光碟中使用 RS 碼進行容錯，防止光碟上的劃痕導致資料不可讀；生活中經常使用的二維碼就利用了RS 碼來提高識別的成功率。近年 RS 碼在分散式儲存系統中的應用被逐漸推廣，一方面是分散式儲存系統儲存的儲存容量和規模增大的需求；另一方面是由於糾刪碼編碼速度在近年得到迅猛提升。隨著對高效能糾刪碼引擎在實際系統中應用需要，也催生了對糾刪碼在具體系統中實現的各種優化手段。併為相關的決策者帶來了困擾——究竟什麼樣的編碼引擎才是高效的呢？
我們將以這個問題展開對糾刪碼技術的剖析，幫助企業更全面，深入的瞭解糾刪碼在儲存系統中的應用並更好地做出技術選型。本系列文章將從糾刪碼的基本原理開始，隨後引出如何判斷編碼引擎優劣這個問題，接下來將深度分析程式碼實現，幫助開發者順利完成定製開發。
本系列共計上下兩篇篇文章：
（上篇）如何選擇糾刪碼編碼引擎
（下篇）實現高效能糾刪碼引擎
本文作為系列首篇，我們將一起探討糾刪碼的編碼原理與如何選擇編碼引擎這兩個問題。
一 、糾刪碼編碼原理
在展開分析之前，我們先來看一看 RS 碼是如何工作的。
下圖展示了 3+2（3 份資料，2 份冗餘）下對 2 位元組長度的資料進行編碼與資料修復過程：
為了計算冗餘資料，首先我們需要選舉出一個合適的編碼矩陣。編碼矩陣的上部為一個單位矩陣，這樣保證了在編碼後原始資料依然可以直接讀取。通過計算編碼矩陣和原始資料的乘積，可以到最終的結果。
下面介紹解碼過程，當 1，2 兩塊資料丟失，即：
當資料塊發生丟失，在編碼矩陣中去掉相應行，等式仍然保持成立。這為我們接下來恢復原始資料提供了依據。
原始資料的修復過程如下：
為了恢復資料，首先我們求剩餘編碼資料的逆矩陣，等式兩邊乘上這個逆矩陣仍然保持相等。與此同時，互逆矩陣的乘積為單位矩陣，因此可以被消掉。那麼所求得的逆矩陣與剩餘塊的資料的乘積就是原始資料了。
資料編碼以位元組為單位，如果將被編碼資料看做一個「陣列」，「陣列」中每個元素是一個位元組，資料按照位元組順序被編碼。編碼過程是計算編碼矩陣中元素和「陣列」的乘積過程。為保證乘積的運算結果仍舊在一個位元組大小以內（即 0-255），必須應用到有限域[1]。有限域上的算術運算不同於通常實數的運算規則。我們通常事先準備好乘法表，並在算術運算時對每一次乘法進行查表得到計算結果。早期的編碼引擎之所以效能不佳，是因為逐位元組查表的效能是非常低的。倘若能一次性對多位元組進行查表以及相應的吞吐和運算，引擎的工作效率必將大幅度提升。
許多 CPU 廠商提供了包含更多位數的暫存器（大於 64 位），這類暫存器和相應支援的運算使得使用者程式可以同時對大於機器位數的資料進行運算，支援這類暫存器和運算的指令稱之為SIMD（Single Instruction Multiple Data）指令集，比如 Intel 支援的 SSE 指令集最大支援 128 bits 的資料運算，AVX2 指令集最大支援 512 bits 的資料運算。它們為我們對一個「陣列」資料分別執行相同的操作，提高了資料運算的並行性。目前，市面上所有高效能的糾刪碼引擎均採用了該項技術以提高編解碼效能。
二、編碼引擎評判標準
我們將從以下幾個關鍵指標來對編碼引擎進行分析：
1、 高編/解碼速度；
2、引數可配置；
3、編碼速度穩定性；
4、程式碼簡潔、穩定；
5 、降低修復開銷等。
2.1 高編/解碼速度
上文提到，依賴於SIMD 技術 RS 碼編碼效能有了大幅度的提高。其中，我們可以利用多種指令集擴充套件以供加速，引擎應該能自動根據 CPU 的特性而選擇最優的指令集擴充套件進行加速。
速度是最基本的要求。不過在這裡我很難給出一個絕對的數字來衡量速度，因為其受引數，執行平臺的影響極大。在下文中提到的三款引擎均有出色的效能表現，可以以它們為基準來衡量引擎的編碼速度。除此之外，我們還可以將逐位元組查表（下稱基本方法）的編碼速度與利用 SIMD 技術加速的編碼速度做對比，兩者之間應該有非常直觀的差距。以我的個人電腦為例（i5-4278U 2.6GHz),在 10+4 的策略下（每個資料塊大小為 128KB），基本方法的速度為（原始資料總量/編碼耗時）318.1 MB/s，而通過 AVX2 指令集加速後達到了 5558.6 MB/s[2],在 SSSE3 指令集的加速下也有 2978.87 MB/s 。
另外，解碼速度應該大於或等於編碼速度（視丟失的資料塊數量而定），下圖截自在我本機上執行的修復原始資料塊的效能測試結果：
2.2 引數可配置
一款合理的糾刪碼引擎必須能做到編碼策略在理論範圍內可隨意切換，這指的是如果要將編碼策略進行變化時，僅需從介面傳入不同引數而不需要改動引擎本身。這大大降低了後續的開發和維護所需要的精力。一個可配置引數的編碼引擎可以根據資料的冷熱程度和資料重要程度選擇不同的編碼係數，比如可靠性要求高的資料可以選擇更多冗餘。
2.3 編碼速度穩定性
速度的穩定性指的是對於不同尺寸的資料塊會有相近的效能表現。由於系統快取的影響，當被編碼資料的大小和快取大小相當時，編碼應該具有最快的速度。當編碼資料的大小大於快取大小時，記憶體頻寬成為編碼速度的瓶頸，檔案大小和編碼時間呈現近似線性關係。這樣，資料編碼時間是可預期的，使用者的服務質量也是可保障的。在實際中，我們對於大檔案進行定長分塊，依次編碼，分塊大小和快取大小保持一定關係：以 10+4 編碼方法為例，對比資料塊尺寸分別為取 L3 Cache Size 的 1/12 以及 12 倍。如 L3 Cache Size 的大小為 12MB，則每一塊的資料尺寸分別取 1MB，144MB。倘若大資料塊下編碼速度遠遠低於小資料塊，則說明該引擎 CPU cache 的優化工作做得不充分。對於上述引數來說，大資料塊的速度應該不低於小資料塊的 70% 。同樣以我的個人電腦為例（L3 Cache 大小為 3MB）：
2.4 程式碼簡潔、穩定
為了利用 SIMD 加速我們不得不引入彙編程式碼或者封裝後的 CPU 指令，因此程式碼形式並不常見。為了增強可讀性可將部分邏輯抽離到高階語言，然而會損失部分效能，這其中的利弊需要根據團隊的研發實力進行權衡。
接下來的可維護性也非常重要。首先是介面穩定，不會隨著新技術的引入而導致程式碼大規模重構；另外程式碼必須經過有合理的測試模組以便在後續的更新中校驗新演算法。
比如早先的 SIMD 加速是基於 SSE 指令集擴充套件來做的，隨後 Intel 又推出 AVX 指令集進一步提高了效能，引擎應該能即時跟上硬體進步的步伐。在比方說，再生碼（可以理解為能減少修復開銷的糾刪碼）是將來發展的趨勢，但我們不能因為演算法的升級而隨意改變引擎的介面。
2.5 降低修復開銷
糾刪碼的一大劣勢便是修復代價數倍於副本方案。k+m 策略的 RS 碼在修復任何一個資料塊時，都需要k 份的其他資料從磁碟上讀取和在網路上傳輸。比如 10+4 的方案下，丟失一個資料塊將必須讀取 10 個塊來修復，這個修復過程佔用大量磁碟 I/O 和網路流量，並使得系統暴露在一種降級的不穩定狀態。因此，實際系統中應該儘量避免使用過大的 k 值。
再生碼[2] 便是為了緩解資料修復開銷而被提出的，它能夠極大減少節點失效時所需要的吞吐的資料量。然而其複雜度大，一方面降低了編碼速度，另外一方面犧牲了傳統 RS 碼的一些優秀性質，在工程實現上的難度也大於傳統糾刪碼。
三、著名引擎對比
目前被應用最廣泛並採用了 SIMD 加速的引擎有如下幾款：
Intel 出品的 ISA-L[4]
J.S.Plank 教授領導的 Jerasure[4]
klauspost 的個人專案（in Golang)[6]
這三款引擎的執行效率都非常高，在實現上略有出入，以下是具體分析：
3.1 ISA-L
糾刪碼作為 ISA-L 庫所提供的功能之一，其效能應該是目前業界最佳。需要注意的是 Intel 採用的效能測試方法與學術界常用的方式略有出路，其將資料塊與冗餘塊的尺寸之和除以耗時作為速度，而一般的方法是不包含冗餘塊的。另外，ISA-L 未對 vandermonde 矩陣做特殊處理，而是直接拼接單位矩陣作為其編碼矩陣，因此在某些引數下會出現編碼矩陣線性相關的問題。好在 ISA-L 提供了cauchy 矩陣作為第二方案。
ISA-L 之所以速度快，一方面是由於 Intel 諳熟彙編優化之道，其次是因為它將整體矩陣運算搬遷到彙編中進行。但這導致了彙編程式碼的急劇膨脹，令人望而生畏。
另外 ISA-L 支援的指令集擴充套件豐富，下至 SSE，上到 AVX512，平臺適應性最強。
3.2 Jerasure2.0
不同於 ISA-L 直接使用匯編程式碼，Jerasure2.0 使用 C 語言封裝後的指令，這樣程式碼更加的友好。另外 Jerasure2.0 不僅僅支援 GF(2^8) 有限域的計算，其還可以進行 GF(2^4) - GF(2^128) 之間的有限域。並且除了 RS 碼，還提供了 Cauchy Reed-Solomon code （CRS 碼）等其他編碼方法的支援。它在工業應用之外，其學術價值也非常高。目前其是使用最為廣泛的編碼庫之一。目前 Jerasure2.0 並不支援 AVX 加速，儘管如此，不過在僅使用 SSE 的情況下，Jerasure2.0 依然提供了非常高的效能表現。不過主要作者之一 James S. Plank 教授轉了研究方向，另外一位作者 Greenan 博士早已加入工業界。因此後續的維護將是個比較大的問題。
3.3 klauspost 的 ReedSolomon
klauspost 利用 Golang 的彙編支援，友好地使用了 SIMD 技術，此款引擎的 SIMD 加速部分是目前我看到的實現中最為簡潔的，矩陣運算的部分邏輯被移到了外層高階語言中，加上 Golang 自帶的彙編支援，使得彙編程式碼閱讀起來更佳的友好。不過 Go 並沒有整合所有指令，部分指令不得不利用 YASM 等彙編編譯器將指令編譯成位元組序列寫入彙編檔案中。一方面導致了指令的完全不可讀，另外一方面這部分程式碼的語法風格是 Intel 而非 Golang 彙編的 AT&T 風格，平添了迷惑。這款引擎比較明顯的缺陷有兩點：1.對於較大的資料塊，編碼速度會有巨大的下滑；2.修復速度明顯慢於編碼速度。
四、自己實現一款引擎
可能是由於對開源庫後續維護問題的擔憂，也有可能是現有方案並不能滿足企業對某些特定需求和偏好，很多公司選擇了自研引擎。那麼如何寫出高效的程式碼呢？在上面的簡單介紹中，受限於篇幅我跳過了很多細節。比如 SIMD 技術是如何為糾刪碼服務的，以及如何利用 CPU Cache 做優化等諸多重要問題。我們會在後續的文章中逐步展開其實現，歡迎大家繼續關注。
附錄：
- 許以超 馬鬆雅. 代數編碼與密碼[M]. 北京:高等教育出版社, 2015.
Alexandros G Dimakis, P Godfrey, Yunnan Wu, Martin J Wainwright, and Kannan Ramchan-dran. Network coding for distributed storage systems. Information Theory, IEEE Transactions on, 56(9):4539–4551, 2010.