一.簡介

在處理和分析資料時，最理想的環境是這樣的：
一臺有無限儲存和計算能力的“超級計算機”，可以提供無窮大的儲存容量，並且可以將計算時間降低至無窮小。

《銀河系漫遊指南》中全宇宙全時空第二強的計算機“深思”，花費750萬年時間，計算出了“宇宙、生命及萬物 ”終極問題的答案：42

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

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

2.橫向擴充套件
使用多臺普通計算機來模擬“超級計算機”。也就是使用多臺機器各自並行地進行儲存和計算這種方式進行模擬。使用這種方式構建的計算機系統叫做分散式系統，它具有以下三個特點：一組計算機、通過網路傳遞資訊、協調計算機的行為。通過這種方式，我們可以近似地獲得無限的儲存和計算能力，解決單機下儲存和計算的侷限。

作為通過網路連線的多臺計算機系統，分散式系統的設計目標一般包括：

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

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

二.問題

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

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

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

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

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

三.不可能

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

圖為歷史上最著名的第一類永動機“魔輪”。人類花費超過500年的時間才學習到：Something is impossible.
P.S. “中華宇宙能源超磁能機車”——即使在永動機歷史上也是非常“出彩”的。可以去百度永動機貼吧長長見識 (╯□╰)

為什麼？我們可以從一致性問題（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定理的深刻理解和靈活運用，構建出了滿足高併發讀寫、處理海量金融資料的分散式資料庫。

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

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