【轉錄】分散式系統原理：困難與不可能性

（有進行慣用語調整）

在處理和分析數據時，最理想的環境是這樣的： 一台有無限存儲和計算能力的「超級電腦」，可以提供無窮大的存儲容量，並且可以將計算時間降低至無窮小。

這樣一台「超級電腦」在現實世界中並不存在。電腦的存儲和計算能力始終要受到客觀物理規律的限制。在可預見的將來，單位存儲單元上無法存儲超量的數據；而在進行運算時，由於晶片計算能力是有限的，當計算需求超過瞬時計算能力時，往往會發生排隊現象。為瞭解決大量數據的存儲和計算能力不足的問題，我們有兩種選擇：

1、縱向擴展：即升級硬體設備。通過如升級存儲量更高的硬碟、單位時間運算速度更高的晶片，可以為電腦提升性能和存儲量，來解決上述問題。但這種硬體的升級會受到電腦本身架構的局限，同時進一步升級所需要的成本會快速上升，從而使得升級硬體的邊際效益快速下降。此外，升級所用的硬體依然具有其自身的局限性，並不能徹底解決上述的問題。

2、橫向擴展：使用多台普通電腦來模擬「超級電腦」。也就是使用多台機器各自並行地進行存儲和計算這種方式進行模擬。使用這種方式構建的電腦機系統叫做分散式系統，它具有以下三個特點：一組電腦機、通過網絡傳遞信息、協調電腦機的行為。通過這種方式，我們可以近似地獲得無限的存儲和計算能力，解決單機下存儲和計算的局限。

作為通過網絡連接的多台電腦系統，分散式系統的設計目標一般包括：

• 擴展性：增加機器不改變或極少改變系統行為，並能獲得近似線性的性能提升。
• 性能：指分散式系統進行服務時的延時和吞吐率是滿足用戶需要的。
• 可用性：分散式系統的核心需求，表示分散式系統是否處於整體可服務並且一直可服務的狀態。
• 容錯性：系統發生錯誤時，系統有對錯誤進行規避和恢復的能力。

通過搭建合理的系統架構，進行恰當的數據管理，分散式系統是可以滿足以上的設計目標的。一套順暢運行的分布式系統可以在很大程度上滿足大量數據的存儲和計算需求。儘管如此，任何事情都需要付出代價。分散式的方式不僅增加了工程複雜性，甚至在理論上會出現不可逾越的障礙。本文將根據GeneDock的分散式實踐經驗對這些優缺點進行必要的探討。

Problem

為了實現分散式系統的設計目標，我們需要先瞭解分散式系統實現過程中需要克服的問題和困難。一套分散式系統的主要物理要素包括節點的數目以及節點間的距離。僅這兩點的更改就會引入以下限制：

• 節點數增加會導致系統整體出錯概率增大。
• 節點數增加會導致節點間通信量增加。
• 節點間距離增加會導致系統最優（或部分）性能變差。

拋開工程的視角，僅從理論層面看，分散式系統也存在著如下三類視角的系統劃分：

• 保持一致：系統中相關數據間的邏輯關係應當是正確和完整的。極端情況下，從系統中任意部分讀取而獲得的數據應當都為最近寫入的數據。
• 處理失效：分散式系統可能出現的失效狀況有三類：節點失效、網絡分區失效、拜佔庭失效。極端情況下，系統的執行和操作不會受到任何系統內部失效的影響。
• 時鐘同步：分布式系統有兩種模型：同步系統和異步系統。同步系統會確保所有執行過程的步調一致，且各執行過程有精確的時鐘。即任意處理過程能夠得到精確的執行流程的偏序關係，也就意味著每個處理過程和通信都在有限的時間內進行。異步系統則相反，沒有任何時序性保證。即各處理過程是完全以自己的節拍在運行，不存在有效的同步時鐘，也意味著過程間的通信延時可能會趨於無窮大。

針對物理層面和理論層面存在的種種問題，分散式系統研究人員希望找到這些問題的答案：是否可以通過硬件技術和軟件算法來克服困難，實現一個理想的或接近理想的分布式系統，以達成模擬那台「超級計算機」的設計目標？

Impossibility

不幸的是，在實際應用中，理想的分布式系統實際是不可能實現的。

圖為歷史上最著名的第一類永動機「魔輪」。

人類花費超過500年的時間才學習到：Something is impossible。為什麼？我們可以從共識問題（Consensus Problem） — — 也就是分散式系統必須解決的一個問題出發，同時考慮其他設計目標，看看可以推導得到什麼樣的結果。

共識問題（Consensus Problem）是指：

• 一致（Agreement）：每個正確的執行過程應該在相同的值上達成一致。
• 完整（Integrity）:每個正確的執行過程最多只能決定一個值。如果它決定了某個值的話，這個值一定是被某個執行過程提出的。
• 終止（Termination）:所有的執行過程最終會做出一個決定。
• 正確（Validity）:如果所有正確的執行過程提出了相同的值V，那麼所有正確的執行過程都會決定值V。

基於以上要求，可以推導出在分布式系統領域非常重要的定理：FLP不可能性 在假設網絡可靠、計算節點只會因崩潰而失效的最小化異步模型系統中，仍然不存在一個可以解決共識問題的確定性算法。 僅這一條定理就已經打碎了我們模擬「超級計算機」的幻想。不過從務實的角度考慮，雖然不能實現理想的分布式系統，但我們是否可以通過對系統主要設計指標進行一定的妥協，來設計出一個理論上可行的、可以滿足實際需求的分布式系統呢？ Trade-off 幸運的是，由Eric Brewer等人提出的CAP定理已經為我們回答了這個問題。CAP定理的一個表述是：

CAP定理

分散式計算系統不可能同時確保一致性、可用性和分區容忍性。

• 一致性（Consistency）:所有節點在同一時刻能夠看到同樣的數據，也即「強一致性」。
• 可用性（Availability）：確保每個請求都可以收到確定其是否成功的響應。
• 分區容忍性（Partition tolerance）:因為網絡故障導致的系統分區不影響系統正常運行。

這也就意味著，我們雖然不能使某個分散式場景同時滿足三個性質，但可以使之同時滿足三個中的兩個。更進一步說，對於包含多個分散式場景的分布式系統，我們甚至可以在三個性質的程度上進行適當的權衡。 CAP權衡方案 我們把解決共識問題（Consensus Problem）的算法叫做共識演算法（Consensus Algorithm）或者共識協議（Consensus Protocol）。CAP定理能夠將這些共識演算法的集合進行歸類：

• C+A：以2階段提交(2 phase commit)為代表的嚴格選舉協議。當通信中斷時算法不具有終止性（即不具備分區容忍性）。
• C+P：以Paxos、Raft為代表的多數派選舉算法。當不可用的執行過程超過半數時，算法無法得到正確結果（即會出現不可用的情況）。
• A+P：以Gossip協議為代表的衝突解決協議。當網絡分區存在和執行過程正確時，只能等待分區消失才保持一致性（即不具備強一致性）

基於CAP定理，我們需要根據不同場景的不同業務要求來進行算法上的權衡。對於分散式存儲系統來說，網絡連接故障是無法避免的。在設計系統時不得不考慮分區容忍性，所以我們實際上只能在一致性和可用性之間進行權衡。 強一致性與可用性的矛盾會導致十分令人頭疼的抉擇。在實際情況中，對於不是那麼重要的數據的存取操作，往往會調低一致性來增加可用性。如GeneDock的賬戶信息管理數據，是以最終一致性的方案分發到各個業務域的，這樣既滿足了各域業務API的性能需求，又使得跨域的賬戶信息同步功能得以實現。當然，對於敏感的元數據信息，GeneDock採取的則是強一致性的方案。知名分散式系統的主場景設計權衡，特別值得一提的經典設計範例是阿里巴巴的OceanBase系統。它將數據分為了冷數據和熱數據兩個不同的場景。對於冷數據，規定只讀不寫。這樣就不需要處理分布式寫操作帶來的一致性問題，只需保證可用性和分區容忍性即可（即AP場景）。而對於新增的熱數據，由於用戶需要頻繁訪問，所以採取不同的服務器分片進行服務，本地讀寫的模式，不需要考慮網絡分區的問題（即CA場景）。通過對CAP定理的深刻理解和靈活運用，構建出了滿足高併發讀寫、處理海量金融數據的分布式數據庫。

Summary

在運算的世界里，一切都是有代價的。我們必須根據業務實際場景，在關鍵的業務指標中進行權衡，進而決定合適的解決方案。必須承認，很多系統聲稱能夠解決的問題其實已經被理論證明是不可實現的，這也客觀上要求用戶在選擇雲端服務提供商的時候一定要擦亮眼睛，不能被過度的宣傳所誤導。

GeneDock的分散式系統解決方案是在深入考量了生物信息分析領域的實際需求，對許多問題做了艱難權衡之後才確定下來的，已經經受住了近兩年的大規模商業計算和存儲業務的考驗。無論是在針對計算量巨大的全基因組分析或BLAST等分析任務，還是在大規模基因數據的存取及傳輸場景中，GeneDock對解決方案都進行了精心的設計和實現，確保任務運行的穩定性、數據存儲的可靠性和數據傳輸的正確性，同時使整體系統運行結果準確一致。

參考資料

• 一致性問題：https://en.wikipedia.org/wiki/Consensus_(computer_science)
• FLP不可能性：http://cs-www.cs.yale.edu/homes/arvind/cs425/doc/fischer.pdf
• CAP定理：https://en.wikipedia.org/wiki/CAP_theorem 來源：https://www.genedock.com/blog/2016/05/27/20160527_distributed_system/

（轉錄自區塊鏈大學）