分散式系統理論 - 從放棄到入門
隨承載用戶數量的增加和容災的需要,越來越多互聯網後台系統從單機模式切換到分散式集群。回顧自己畢業五年來的工作內容,同樣有這樣的轉變。
畢業頭兩年負責維護運行在刀片機上的業務,在機房裡拔插單板的日子是我逝去的青春。設備之間通過VCS組成冷備,但即使有雙機軟體保護,宕機、網路丟包等問題發生時業務仍會受影響。這樣的系統架構下為保證SLA,有時候需要深入Linux系統內核或硬體層面分析機器重啟的原因。
接下來負責維護承載在分散式集群上的業務,相比前面的工作,這個階段主要關注點不是單節點的異常,更多是系統整體的穩定和健壯。面對紛繁複雜的系統,剛開始的時候有這樣的感覺:
龐大複雜的分散式系統前,應該從哪方面入手提升對其的認識和理解、提升專業性?網上可以找到很多分散式系統相關的論文和資料,但歸納起來要表達的主要意思是什麼?
結合自己這幾年的工作經驗,總結分散式系統的核心就是解決一個問題:不同節點間如何達成共識。
看似簡單的問題因網路丟包、節點宕機恢復等場景變得複雜,由此才衍生出很多概念、協議和理論。為探究共識問題最大能解決的程度,於是有FLP、CAP邊界理論;為在特定條件和範圍內解決該問題,於是有一致性協議Paxos、Raft、Zab和Viewstamped Replication;為構建這些協議,於是有多數派、Leader選舉、租約、邏輯時鐘等概念和方法。
2016年我閱讀了分散式系統領域一些代表性的論文和博文,圍繞「不同節點如何達成共識」這個問題,加入自己的認識和理解後有下面7篇小結:
一致性、2PC和3PC
選舉、多數派和租約時間、時鐘和事件順序CAP
PaxosRaft、ZabPaxos變種和優化構思和寫作技術類文章是一個辛苦的過程,一方面要閱讀很多資料並轉化成自己的理解、找到盡量不拾人牙慧的立意和角度,一方面要絞盡腦汁組織語言讓預期的讀者能夠容易理解。
但它也是一個有趣的過程,把知識捋一遍後原本一些模糊的概念變得清晰,希望這幾篇整理能為系統性地介紹分散式理論中文資料添一塊磚、加一片瓦。
推薦閱讀:
※CAP 理論常被解釋為一種「三選二」定律,這是否是一種誤解?
※zhh-2015在分散式系統和資料庫領域研究水平和工程能力怎樣?
※大數據計算框架除了 MapReduce 還有哪些呢,不應該是 MapReduce 去解決所有問題吧?
※到現在為止,NoSQL運動給資料庫系統留下什麼寶貴的思想?
※為什麼很多分散式系統都是以DAG(Directed acyclic graph )實現運算的?
TAG:分布式系统 |