http://blog.sina.com.cn/s/blog_57f61b490102viq9.html
1.前言
Swift升級到2.0大版本后宣稱開始支持糾刪碼，這其實是一個很有意義的特性，主要是能夠在一定程度上解決3副本空間浪費太多的問題。因為3副本這一點是swift推廣的最大障礙之一，成本的增加嚇退了不少潛在客戶。這次的改進有望消除客戶顧慮，拓展更多用戶
而回到存儲領域來看，數據冗余機制其實這幾十年來沒有太多進展，RAID，副本一直是當仁不讓的最終選擇。而近幾年，尤其是規模較大的應用場景下，糾刪碼越來越多的出現在選擇的視野范圍，成為RAID，副本之外的第三種選擇，因此也獲得了越來越多的關注。
糾刪碼（Erasure Code)本身是一種編碼容錯技術，最早是在通信行業解決部分數據在傳輸中損耗的問題，它的基本原理是把傳輸的信號分段，加入一定的校驗再讓各段間發生一定的聯系，即使在傳輸過程中丟失掉部分信號，接收端仍然能通過算法把完整的信息計算出來。
如果嚴格的區分，實際上按照誤碼控制的不同功能，可分為檢錯、糾錯和糾刪三種類型。檢錯碼僅具備識別錯碼功能 而無糾正錯碼功能；糾錯碼不僅具備識別錯碼功能，同時具備糾正錯碼功能；糾刪碼則不僅具備識別錯碼和糾正錯碼的功能，而且當錯碼超過糾正范圍時，還可把無法糾錯的信息刪除。
前面曾提到過適用場景通常是大規模部署，這是有其緣由的。從傳統情況來看，RAID通常用在企業級環境里較多，在幾台和十幾台存儲設備規模的IT系統中，一向是使用穩定可靠歷經數十年磨礪的RAID技術。而在數據中心級的大規模部署中，RAID不再受歡迎，大部分的分布式系統都偏好副本模式，看重的是其高可靠性和讀性能優化的特點（關於副本的討論我之前寫過一篇：為啥大家都喜歡3副本，是拍腦袋的嗎？http://blog.sina.com.cn/s/blog_57f61b490101a8ca.html）。然而副本帶來的成本壓力實在是有些吃不消，這時候Erasure Code適時出現，以更低成本和更高技術含量提供近似可靠性這幾點，就吸引到了眾多分布式存儲／雲存儲的廠商和用戶。
2. 糾刪碼理論分析
糾刪碼常見的有三類，Reed-Solomen類，級聯低密度糾刪碼和數字噴泉碼，后面兩種的實現原理細節和優劣這里就不深入了，這里只簡單介紹下目前在存儲行業應用的Reed-Solomen類糾刪碼。
從糾刪碼基本的形態來看，它是N個數據+M個校驗的結構，其中數據和校驗的N和M值都能夠按照一定的規則設定。在1～M個數據塊（數據或校驗都行）損壞的情況下，整體數據仍然可以通過計算剩余數據塊上面的數據得出，整體數據不會丟失，存儲仍然是可用。
下面是糾刪碼的結構示意圖。
從圖中其實可以看出，糾刪碼和大家熟悉的RAID技術看起來是有些類似的，一個條帶（Stripe）是由多個數據塊（strip）構成，分為數據塊和校驗塊。但與RAID5/RAID6不同的是，糾刪碼功能上來看最大的區分特點是校驗和數據的比例按N+M可調整，並且校驗塊數量不再受限於兩個，典型的如12+4，6+3等等。
校驗塊和數據之間是如何建立關系的呢？通信理論（鄙人專業）告訴我們糾刪碼是屬於分組線性編碼，編碼過程用到的數學理論並不高深，數學關系其實是是矩陣乘法。具體來說是用編碼矩陣和分塊數據做乘法從而得到校驗塊，如下：
在建立完關聯后，由於矩陣運算是可逆，系統就具備了容忍最大M個失效的能力。
（微軟曾在一次演示中用兩數之和等於第三個數來解釋，但僅是為了方便理解，在真正實踐的多校驗情況下，還是使用編碼矩陣的。）
https://www.usenix.org/conference/atc12/technical-sessions/presentation/huang
3. 糾刪碼的演化，RS->LRC
糾刪碼通過技術含量較高的算法，提供和副本近似的可靠性，同時減小了額外所需冗余設備的數量，從而提高了存儲設備的利用率。但糾刪碼所帶來的額外負擔主要是計算量和數倍的網絡負載，優缺點都相當明顯。尤其是在出現硬盤故障后，重建數據非常耗CPU，而且計算一個數據塊需要通過網絡讀出N倍的數據並傳輸，所以網絡負載也有數倍甚至10數倍的增加。
整體來看，若采用糾刪碼技術，你能夠得到了希望的容錯能力和存儲資源利用率，但是需要接受一定的數據重建代價，兩者間做一個平衡。
難道事情就這個樣子了嗎？有沒有優化改善的空間呢？答案是“有”。
如果仔細分析故障出現的情況，你將很容易發現兩個特征：
特征一：所有的故障都將導致同樣的重建代價，無論是一個盤，還是M個盤
特征二：單個磁盤故障的幾率遠遠大於多個磁盤同時故障的幾率，通常在90%以上
因此，優化的思路自然聚集到更容易出現的單個磁盤故障上來，如何更有效的處理這種概率較大的事件呢，直接出現的對策就是分組，把單個磁盤故障影響范圍縮小到各個組內部，出壞盤故障時，該組內部解決，在恢復過程中讀組內更少的盤，跑更少的網絡流量，從而減小對全局的影響。
LRC（Locally Repairable Codes），我理解為局部校驗編碼，其核心思想為：將校驗塊（parity block）分為全局校驗塊(global parity)、局部校驗塊(local reconstruction parity)，故障恢復時分組計算。
以微軟Azure的雲存儲（Windows Azure Storage）實現為例，它采用LRC（12,2,2）編碼，將12個數據塊為一組編碼，並進一步將這12個數據塊平均分為2個本地組， 每個本地組包括6個數據塊，並分別計算出一個local parity，之后把所有12個數據塊計算出2個global parities。
當發生任何一個數據塊錯誤時，只需用本地組內的數據和校驗塊用於計算，即可恢復出原始數據。而恢復代價（通過網絡傳輸的數據塊數量）就由傳統RS（12,4）編碼的12，變為6，恢復過程的網絡I/O開銷減半，同時空間冗余率保持不變，仍為（12+2+2）/12 = 1.33
微軟在介紹中有過一張圖來對RS和LRC進行對比，我覺得描述的非常清楚，這里借用一下
圖中，藍色是LRC，紅色是RS，可以很清楚的看到，使用LRC的編碼方式后，雖然空間利用率（橫軸）並沒有提高，但是重建代價（縱軸）卻有明顯的改善。考慮到分布式系統里故障是一個常態，重建代價的降低和局部化就是非常有價值的一個技術改進了。
另外，有一點要特別注意，LRC並不是100%不丟數據的，4個塊壞掉的情況下，只有86%的幾率能找回數據，從可靠性排序來說，RS12+4 》 LRC12+2+2 》RS6+3。
但綜合來說，LRC還是很有競爭力的技術，目前，Microsoft、Google、Facebook、Amazon、淘寶（TFS）都已經在自己的產品中采用了Erasure Code，並且大多都從經典RS轉向LRC。雖然具體實現，但基本原理都是LRC的組內校驗+全局校驗。
4. 糾刪碼的實際案例
我們可以具體來看看在業界，各家優化版糾刪碼的實現是怎么樣的。
Google RS(6,3) in GFS II (Colossus)，
Google在04年發布GFS的經典論文后，09年開始開發第二代GFS（Colossus），它采用了最基本的RS（6,3）編碼，將一個待編碼數據單元(Data Unit)分為6個數據塊, 再添加3個parity block，最多可容包括parity blocks在內的任意3個數據塊錯誤。
數據恢復的網絡I/O開銷為：恢復任何一個數據塊需要6次I/O，通過網絡傳輸6個數據block，存儲的空間冗余率 為（6+3)/6 = 1.5
由於Google的信息能查閱到的有限，我沒找到近兩年的情況介紹，但相信Google這樣一家技術型的公司，應當也有類似的演進后的糾刪碼技術，不會止步於5年前的RS標准碼。
Facebook：從RS(10,4)到LRC（10,6,5）
Facebook早期在HDFS RAID中采用的編碼方式RS(10,4)
如上圖所示。將每個待編碼的數據均分為10個數據塊, 后面添加4個校驗的parity校驗塊。這種RS編碼方式的空間冗余率為（10+4）/10 = 1.4x,發生任何一個數據塊錯誤的恢復代價為10，即發生任意一個塊錯誤需要10次I/O操作，從網絡傳輸的數據量為10個數據塊。
同樣為減少數據恢復的網絡I/O代價, FaceBook在13年和加州大學共同發表了論文， XORing Elephants: Novel Erasure Code for Big Data，並把這一成果用在“進階版HDFS”上
其LRC編碼方法如下：
除了在原先的10個數據塊之后添加4個校驗塊外，還將10個數據塊均分為2組，每組單獨計算出一個局部校驗塊（Parity），將數據恢復代價由原來的10降低為5.即恢復任何一個數據塊錯誤只需要進行5次網絡I/O，從網絡傳輸5個數據塊。此種編碼方式的空間冗余率 為（10+4+2）/10 = 1.6。
4. 結論
相對副本而言，糾刪碼（erasure code）的編碼技術無疑對存儲空間利用率帶來很大提升，但由於引入額外的編碼、解碼運算，對分布式系統的計算能力和網絡都有一定額外的要求，簡單的理解就是硬件性能要升級，網絡環境也得要升級，升級的代價在目前階段還是一筆不小的預算。
而由於性能損失的原因，用在本身壓力已經很大，很“熱”的在線存儲系統明顯不是很合適，所以目前大多數系統還是把erasure code用於冷數據的離線處理階段。
LRC編碼由於減少了網絡I/O傳輸的數據量，參與數據恢復運算的數據量和重建時間都基本上能夠縮短一倍，但卻是以可靠性和空間利用率的一定犧牲為代價的。如何更加有效的實現還是要結合實際項目需求，綜合考量，有更多的實際工作要做。