認識分散式架構

認識分散式架構

隨著計算機系統規模變得越來越大，將所有的業務單元集中部署在一個或若干個大型機上的體系結構，已經越來越不能滿足當今計算機系統，尤其是大型網際網路系統的快速發展，各種靈活多變的系統架構模型層出不窮。分散式的處理方式越來越受到業界的青睞——計算機系統正在經歷一場前所未有的從集中式向分散式架構的變革。

集中式與分散式

集中式系統

所謂的集中式系統就是指由一臺或多臺主計算機組成中心節點，資料集中儲存於這個中心節點中，並且整個系統的所有業務單元都集中部署在這個中心節點上，系統的所有功能均由其集中處理。

集中式系統的最大的特點就是部署結構非常簡單，底層一般採用從IBM、HP等廠商購買到的昂貴的大型主機。因此無需考慮如何對服務進行多節點的部署，也就不用考慮各節點之間的分散式協作問題。但是，由於採用單機部署，很可能帶來系統大而複雜、難於維護、發生單點故障（單個點發生故障的時候會波及到整個系統或者網路，從而導致整個系統或者網路的癱瘓）、擴充套件性差等問題。

分散式系統

分散式系統是一個硬體或軟體元件分佈在不同的網路計算機上，彼此之間僅僅通過訊息傳遞進行通訊和協調的系統。簡單來說就是一群獨立計算機集合共同對外提供服務，但是對於系統的使用者來說，就像是一臺計算機在提供服務一樣。分散式意味著可以採用更多的普通計算機（相對於昂貴的大型機）組成分散式叢集對外提供服務。計算機越多，CPU、記憶體、儲存資源等也就越多，能夠處理的併發訪問量也就越大。

從分散式系統的概念中我們知道，各個主機之間通訊和協調主要通過網路進行，所以分散式系統中的計算機在空間上幾乎沒有任何限制，這些計算機可能被放在不同的機櫃上，也可能被部署在不同的機房中，還可能在不同的城市中，對於大型的網站甚至可能分佈在不同的國家和地區。但是，無論空間上如何分佈，一個標準的分散式系統應該具有以下幾個主要特徵：

• 分佈性

  分散式系統中的多臺計算機之間在空間位置上可以隨意分佈，同時，機器的分佈情況也會隨時變動。

• 對等性

  分散式系統中的計算機沒有主／從之分，即沒有控制整個系統的主機，也沒有被控制的從機，組成分散式系統的所有計算機節點都是對等的。副本（Replica）是分散式系統最常見的概念之一，指的是分散式系統對資料和服務提供的一種冗餘方式。在常見的分散式系統中，為了對外提供高可用的服務，我們往往會對資料和服務進行副本處理。資料副本是指在不同節點上持久化同一份資料，當某一個節點上儲存的資料丟失時，可以從副本上讀取該資料，這是解決分散式系統資料丟失問題最為有效的手段。另一類副本是服務副本，指多個節點提供同樣的服務，每個節點都有能力接收來自外部的請求並進行相應的處理。

• 併發性

  在一個計算機網路中，程式執行過程的併發性操作是非常常見的行為。例如同一個分散式系統中的多個節點，可能會併發地操作一些共享的資源，如何準確並高效地協調分散式併發操作也成為了分散式系統架構與設計中最大的挑戰之一。

• 缺乏全域性時鐘

  在分散式系統中，很難定義兩個事件究竟誰先誰後，原因就是因為分散式系統缺乏一個全域性的時鐘序列控制。

• 故障總是會發生

  組成分散式系統的所有計算機，都有可能發生任何形式的故障。除非需求指標允許，在系統設計時不能放過任何異常情況。

分散式系統面臨的問題

• 通訊異常

  分散式系統需要在各個節點之間進行網路通訊，因此網路通訊都會伴隨著網路不可用的風險或是系統不可用都會導致最終分散式系統無法順利完成一次網路通訊。另外，即使分散式系統各節點之間的網路通訊能夠正常進行，其延時也會遠大於單機操作，會影響訊息的收發的過程，因此訊息丟失和訊息延遲變得非常普遍。

• 網路分割槽

  當網路由於發生異常情況，導致分散式系統中部分節點之間的網路延時不斷增大，最終導致組成分散式系統的所有節點中，只有部分節點之間能夠進行正常通訊，而另一些節點則不能——我們將這個現象稱為網路分割槽，就是俗稱的“腦裂”。當網路分割槽出現時，分散式系統會出現區域性小叢集，在極端情況下，這些區域性小叢集會獨立完成原本需要整個分散式才能完成的功能，這就對分散式一致性提出類非常大的挑戰。

• 三態

  分散式系統的每一次請求與響應，存在特有的“三態”概念，即成功、失敗與超時。當出現超時現象時，網路通訊的發起方是無法確定當前請求是否被成功處理的。

• 節點故障

  節點故障則是分散式環境下另一個比較常見的問題，指的是組成分散式系統的伺服器節點出現的當機或“僵死”現象。

分散式事務

在單機資料庫中，我們很容易能夠實現一套滿足ACID特性的事務處理系統，但在分散式資料庫中，資料分散在不同的機器上，如何對這些資料進行分散式的事務處理具有非常大的挑戰。但是在分散式計算領域，為了保證分散式應用程式的可靠性，分散式事務是無法迴避的。

分散式事務是指事務的參與者、支援的伺服器、資源伺服器以及事務管理器分別位於分散式系統的不同節點之上。通常一個分散式事務中會涉及對多個資料來源或業務系統的操作。一個最典型的分散式事務場景：一個跨銀行的轉賬操作涉及呼叫兩個異地的銀行服務，其中一個是本地銀行提供的取款服務，另一個則是目標銀行提供的存款服務，這兩個服務本身是無狀態並且是互相獨立的，共同構成了一個完整的分散式事務。

對於一個高訪問量、高併發的網際網路分散式系統來說，如果我們期望實現一套嚴格滿足ACID特性的分散式事務，很可能出現的情況就是在系統的可用性和嚴格一致性之間出現衝突——因為當我們要求分散式系統具有嚴格一致性時，很可能就需要犧牲掉系統的可用性。但毋庸置疑的一點是，可用性又是一個所有消費者不允許我們討價還價的系統屬性，比如淘寶網這樣線上網站就要求能夠7*24小時不間斷地對外提供服務，而對於一致性，則更加是所有消費者對於一個軟體系統的剛需。因此，在可用性和一致性之間永遠無法存在一個兩全其美的方案，於是如何構建一個兼顧可用性和一致性的分散式系統成為了無數工程師探討的難題，出現了諸如CAP和BASE這樣的分散式系統經典理論。

CAP定理

CAP理論告訴我們，一個分散式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分割槽容錯性（P：Partition tolerance）這三個基本需求，最多隻能同時滿足其中的兩項。

• 一致性

  在分散式環境中，一致性是指資料在多個副本之間是否能夠保持一致性的特性。在一致性的需求下，當一個系統在資料一致性的狀態下執行更新操作後，應該保證系統的資料仍然處於一致的狀態。在分散式系統中，如果能夠做到針對一個資料項的更新操作執行成功後，所有的使用者都可以讀取到其最新的值，那麼這樣的系統被認為具有強一致性（或嚴格的一致性）。

• 可用性

  可用性是指系統提供的服務必須一直處於可用的狀態，對於使用者的每一個操作請求總是能夠在有限的時間內返回結果。

• 分割槽容錯性

  分割槽容錯性約束了一個分散式系統需要具有如下特性：分散式系統遇到任何網路分割槽故障的時候，仍然需要能夠保證對外提供滿足一致性的可用性的服務，除非是整個網路環境環境都發生了故障。需要注意的是，組成一個分散式系統的每個節點的加入與退出都可以看作是一個特殊的網路分割槽。

在進行對CAP定理的應用時，我們就需要拋棄其中的一項，下表是拋棄CAP定理中任意一項特性的場景說明。

放棄CAP定理	說明
放棄P	如果希望能夠避免系統出現分割槽容錯性問題，一種較為簡單的做法是將所有的資料都放在一個分散式節點上。這樣的做法雖然無法100%地保證系統不會出錯，但至少不會碰到由於網路分割槽帶來的負面影響。但同時需要注意的是，放棄P的同時也就意味著放棄類系統的可擴充套件性
放棄A	放棄可用性，一旦系統遇到網路分割槽或其他故障時，那麼受到影響的服務需要等待一定的時間，因此在等待期間系統無法對外提供正常的服務，即不可用
放棄C	事實上，放棄一致性指的是放棄資料的強一致性，而保留資料的最終一致性。這樣的系統無法保證資料保持實時的一致性，但是能夠承諾的是，資料最終會達到一個一致的狀態。這就引入了一個時間視窗的概念，具體多久能夠達到資料一致取決於系統的設計，主要包括資料副本在不同節點之間的複製時間長短

對於一個分散式系統，分割槽容錯性可以說是一個最基本的要求。既然是分散式系統，那麼分散式系統中的元件必然需要被部署到不同的節點，否則也就無所謂分散式系統了，因此必然出現子網路。而對於分散式系統而言，網路問題又是一個必定會出現的異常情況，因此分割槽容錯性也就稱為了一個分散式系統必然需要面對和解決的問題。因此係統架構設計師往往需要把精力花在如何根據業務特點在C（一致性）和A（可用性）之間尋求平衡。

BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，是由eBay的架構師提出的。BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模網際網路系統分散式實踐的總結，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

• 基本可用

  基本可用是指分散式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價於系統不可用。“基本可用”的典型例子：

  1、響應時間上損失：正常情況下，一個線上搜尋引擎需要在0.5秒之內返回給使用者相應的查詢結果，但由於出現故障，查詢結果的響應 時間增加到了1-2秒。

  2、功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在大促購物高峰的時候，由於消費 者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能被引導到一個降級頁面。

• 弱狀態

  弱狀態也稱為軟狀態，和硬狀態相對，是指允許系統中的資料存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的資料副本之間進行資料同步的過程存在延時。

• 最終一致性

  最終一致性強調的是系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終資料能夠達到一致，而不需要實時保證系統資料的強一致性。

參考資料

從Paxos到Zookeeper分散式一致性原理與實踐