在10月19日的雲栖社群線上教育訓練上，來自盤古團隊的吳洋分享了《盤古：飛天分布式存儲系統實踐》。他主要從以下三個方面進行了分享：盤古是什麼？盤古是用來解決什麼問題的？盤古是怎麼解決問題的？他主要介紹了盤古的分布式系統架構和設計理念。
本次視訊直播的整理文章整理完畢，如下内容。
上圖列舉了目前主流的雲計算廠商，我們發現一個很有趣的事情：所有雲計算廠商都是“富二代”，它們的分布式存儲技術全部采用自研技術，而沒有用大家耳熟能詳的開源分布式系統。
第一代飛天人的夢想是在大量廉價的pc伺服器上，對外提供各種計算和存儲服務。具體到以下幾個元件：誇父，主要負責網絡；女娲，主要負責協同；伏羲，主要負責排程；盤古，主要負責存儲；神農，主要負責監控。
上圖介紹了盤古的底層存儲平台，其承擔承上啟下的作用。盤古作為分布式存儲系統，主要提供兩種類型的接口：append only接口，random access接口。
單機的硬體或者系統總是不完美的，總是會小機率的出錯，但是它又需要具有大規模下水準擴充的能力，因為它要管理大量的機器。這兩個層面放在一起意味着出錯是常态。
4%磁盤年損壞率，1%%機器日當機率
raid卡崩潰、電容充放電導緻write back模式變成write through
網絡分割、交換機丢包、更新重新開機、光纖損壞帶寬降低90%、兩地機房路由錯誤
機架斷電、整個機房掉電
網卡tcp校驗出錯，磁盤通路資料校驗出錯
ntp時間漂移、核心io線程d狀态、dirty page cache無法寫回
系統熱點無時不在，瞬時轉移
程式缺陷導緻資源洩露、建立大量檔案、通路髒資料
誤操作：誤删資料、拔錯磁盤、沒有清理測試機器環境上線……
從上圖可以看到，作為統一存儲，要支援虛拟機中的塊存儲，對象存儲，表格存儲，檔案存儲，離線大資料處理，大資料分析等諸多業務，其面臨的挑戰是很大的，甚至有些挑戰是自相沖突的。
盤古在系統設計的時候進行了一些取舍。首先盤古使能了更多的雲産品，讓雲産品去對接使用者，這樣就可以集中精力打造一個穩定可靠的分布式存儲平台。高可靠、高可用是不能妥協的部分，在任何情況下要保證資料的強一緻性、正确性、可靠性、可用性。有的時候追求低成本會威脅到高可用，是以要做到高性能、合理成本，提供高成本效益的線上存儲。易用、服務化，友善使用者輕量接入、無感覺運維完善好用的監控、工具、文檔。
分為三個部分：client，master，chunkserver。需要發起一次寫入的時候，client向master建立一個檔案，并且打開這個檔案，此時master會選好三個副本的位置回報給client。client根據三個副本的位置找到chunkserver，把資料寫進去。也就是說，client做整體的控制，master提供源資料的存儲，chunkserver提供資料的存儲。系統中的單點是非常脆弱的，如何保證其高可用？盤古的第一步是加入一個paxos，也就是說用很多台master組成一個group來實作高可用。即使用很多台伺服器來實作高可用，最終對外服務的隻能是一台伺服器，當記憶體資料足夠多的時候，就需要水準擴充。mounttable可以把目錄樹劃分成volume，通過不同的volume就可以實作master的水準擴充。
盤古三副本強一緻，三副本位于不同的故障域，故障時自動資料複制。如上圖所示，一個資料中心有3份資料存放在4個rack中，如果rack-1突然斷電或者網絡有問題。此時，比如菱形的資料原來在rack-3、rack-4上，當rack-1的菱形資料丢失時，盤古會通過高效的算法從rack-3上複制一份出來放入rack-2，保證了資料的安全可靠。
盤古主要做了兩件事：端到端的資料校驗，靜默錯誤檢查。在小機率下，記憶體存儲的資料是可能發生變化的，磁盤上存儲的資料也會發生變化。每段資料後面都有crc，這樣，一旦寫入磁盤，資料和crc是能夠比對上的，背景周期性掃描，發現資料和crc不比對時就判定這段資料發生了位反轉，那麼用其他好的副本将其覆寫。
盤古進行了合理成本的優化。比如，線下運作的單叢集有上萬台，數百pb的資料。單組master也進行了優化，讀能達到15w qps，寫能達到5w qps。單資料節點進行了軟體棧極限優化，使得軟體的消耗非常低，并且分層存儲。最後，為了實作低成本，使用了普通pc伺服器、erasure code。
運維是非常重要的，盤古實作了熱更新應用無感覺，運維操作根據配置自動化執行，不需要人工幹預，通過環境标準化及時糾正，通過問題診斷自我解決問題。結構如上圖所示，有一個集中管理的配置管理庫，盤古管控中心會把配置管理庫推送到盤古的各個元件，自動執行配置變更，發現配置不對時能夠實作自動對齊，運作環境标準化檢查對于大規模的分布式系統是非常重要的。
分布式系統的核心是面向容錯的設計：
資料安全是一種信仰：e2e checksum；背景靜默掃描；系統bug，硬體故障，運維操作的容錯。大規模的系統中，總會遇到各種各樣的問題，當這些問題攪在一起時就會變得非常棘手。
環境檢查排除隐患：磁盤分區；機架分布；配置錯誤；軟體錯誤；硬體錯誤。
單機失效無感覺：資料複制保證安全；換機器重試保證讀寫成功；記憶并規避故障機器。
監控+自愈：master自我健康檢查進行切換；chunkserver發現故障磁盤或機器進行隔離；client檢測服務狀況進行master切換；client自我健康檢測并彙報狀态。
以上的設計大大減小了運維的壓力。
master需要解決的主要是三類問題：大容量、高效、穩定。大容量是指：federation水準擴充，記憶體緊緻排列單組支援8億檔案，讀寫ops 100k/s。高效意味着最優的算法，硬體錯誤觸發快速複制保證資料安全，資料流量動态規劃實作最大吞吐，安全域動态調整保證資料高可用。穩定即paxos資料一緻、防止單點，多角度監控自動觸發切換，多使用者隔離防打死。由于盤古是多租戶的系統，比如一萬台的叢集上面會跑着各種各樣的應用，其互相之間是不知道的，但是它們在共用一個master機器。如果一個使用者大量通路master，這時整個叢集都不能提供對外服務，怎麼杜絕這種情況？盤古做了多重隔離解決了上述問題。
chunkserver面臨的問題是：閃存的價格高，iops高；機械硬碟價格低，iops低；隻寫入記憶體的方案掉電會丢失資料。如果整個叢集都掉電，那麼記憶體中還沒寫入資料就會丢掉，如果三份備份資料都丢掉，這對雲計算是不能接受的事情。怎麼結合閃存、機械式硬碟以最低的成本解決上述問題？有些解決方案使用ups，但是ups也存在不可靠問題，資料仍然會丢失。是以，最終的解決方案是使用少量的緩存搭配大量的機械硬碟，資料前台先寫入緩存，背景将其轉儲到機械式硬碟。
client面臨很多問題，很多現在的程式設計語言中，協程是非常普及的事情。傳統的多線程程式設計中，多核系統上線程較多時，切換代價非常高，高性能的程式無法容忍這一點。有些解決方案是異步的程式設計，這樣就使用少數的線程、不切線程。怎麼樣既有同步程式設計的便利，又有異步程式設計的性能？協程就是解決方案，很多現在的程式設計語言本身已經提供了協程，但是c++沒有提供協程，是以盤古自己通過實作協程獲得了高性能。client面臨的問題是：有些使用者需要極緻的性能，有些使用者需要程式設計的簡便，已有的海量程式要無縫支援。解決上述問題的方案是使用線程同步原語同時支援協程和非協程使用者。在協程中是不切線程的，是以意味着所有的task都在一個線程中執行，如果任何一個task有阻塞操作，都會導緻整個線程吞吐率的降低。