本文內容參考網路，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解常見的分散式技術、以及一些較為常見的分散式系統概念，同時也需要進一步瞭解zookeeper、分散式事務、分散式鎖、負載均衡等技術，以便讓你更完整地瞭解分散式技術的具體實戰方法，為真正應用分散式技術做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

本文較為粗略地講述了CAP與BASE理論，以及分散式系統需要解決的一些問題，更加系統的理論可以參考後面的分散式系統理論專題文章。更加詳細的實踐內容也可以參考本專題的剩餘文章

## 1、分散式

小明的公司又3個系統：系統A，系統B和系統C，這三個系統所做的業務不同，被部署在3個獨立的機器上執行，他們之間互相呼叫（當然是跨域網路的），通力合作完成公司的業務流程。

將不同的業務分部在不同的地方，就構成了一個分散式的系統，現在問題來了，系統A是整個分散式系統的臉面，使用者直接訪問，使用者訪問量大的時候要麼是速度巨慢，要麼直接掛掉，怎麼辦？

由於系統A只有一份，所以會引起單點失敗。。。

## 2、叢集（Cluster）

小明的公司不差錢，就多買幾臺機器吧， 小明把系統A一下子部署了好幾份（例如下圖的3個伺服器），每一份都是系統A的一個例項，對外提供同樣的服務，這樣，就不怕其中一個壞掉了，還有另外兩個呢。

這三個伺服器的系統就組成了一個叢集。

可是對使用者來說，一下子出現這麼多系統A，每個系統的IP地址都不一樣，到底訪問哪一個呢？

如果所有人都訪問伺服器1.1，那伺服器1.1會被累死，剩下兩個閒死，成了浪費錢的擺設

## 3、負載均衡（Load Balancer）

小明要儘可能的讓3個機器上的系統A工作均衡一些，比如有3萬個請求，那就讓3個伺服器各處理1萬個（理想情況），這叫負載均衡

很明顯，這個負載均衡的工作最好獨立出來，放到獨立的伺服器上（例如nginx）：

後來小明發現，這個負載均衡的伺服器雖然工作內容簡單，就是拿到請求，分發請求，但是它還是有可能掛掉，單點失敗還是會出現。

沒辦法，只好把負載均衡也搞成一個叢集，bug和系統A的叢集有兩點不同：

1.這個新的叢集中雖然有兩個機器，但是我們可以用某種辦法，讓這個機器對外只提供一個IP地址，也就是使用者看到的好像只有一個機器。

2.同一時刻，我們只讓一個負載均衡的機器工作，另外一個原地待命，如果工作的那個拐到了，待命的那個就頂上去。

## 4、彈性

如果3個系統A的例項還是滿足不了大量請求，例如雙十一，可以申請增加伺服器，雙十一過後，新增的伺服器閒置，成了擺設，於是小明決定嘗試雲端計算，在雲端可以輕鬆的建立，刪除虛擬的伺服器，那樣就可以輕鬆的隨著使用者的請求動圖的增減伺服器了。

## 5、失效轉移

上面的系統看起來很美好，但是做了一個不切實際的假設：

所有的服務都是無狀態的，換句話說，假設使用者的兩次請求直接是沒有關聯的。

但是現實是，大部分服務都是有狀態的，例如購物車。

使用者訪問系統，在伺服器上建立了一個購物車，並向其中加了幾個商品，然後伺服器1.1掛掉了，使用者後續訪問就找不到伺服器1.1了，這時候就要做失效轉移，讓另外幾個伺服器去接管，去處理使用者的請求。

可是問題來了，在伺服器1.2,1.3上有使用者的購物車嗎？如果沒有，使用者就會抱怨，我剛建立的購物車哪裡去了？

還有更嚴重的，假設使用者登入過得資訊儲存到了該伺服器1.1上登入的，使用者登入過的資訊儲存到了該伺服器的session中，現在這個伺服器掛了，用的session就不見了，會把使用者踢到了登入介面，讓使用者再次登入！

處理不好狀態的問題，叢集的威力就大打折扣，無法完成真正的失效轉移，甚至無法使用。

## 怎麼辦？

一種辦法是把狀態資訊在叢集的各個伺服器之間複製，讓叢集的各個伺服器達成一致，誰來幹這個事情？只能像Webspher，Weblogic這樣的應用伺服器了。

還有一種辦法， 就是把狀態資訊幾種儲存在一個地方，讓叢集伺服器的各個伺服器都能訪問到：

小明聽說Redis不錯，那就用Redis來儲存吧！

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

## 集中式與分散式
集中式系統

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

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

分散式系統

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

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

### 分佈性

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

### 對等性

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

### 併發性

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

### 缺乏全域性時鐘

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

### 故障總是會發生

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

## 分散式系統面臨的問題
### 通訊異常

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

### 網路分割槽

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

### 三態

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

### 節點故障

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

## 分散式理論(一) - CAP定理
前言
CAP原則又稱CAP定理，指的是在一個分散式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性）這三個基本需求，最多隻能同時滿足其中的2個。

初探分散式理論
正文
### 1. CAP原則簡介
選項	描述
Consistency（一致性）	指資料在多個副本之間能夠保持一致的特性（嚴格的一致性）
Availability（可用性）	指系統提供的服務必須一直處於可用的狀態，每次請求都能獲取到非錯的響應（不保證獲取的資料為最新資料）
Partition tolerance（分割槽容錯性）	分散式系統在遇到任何網路分割槽故障的時候，仍然能夠對外提供滿足一致性和可用性的服務，除非整個網路環境都發生了故障
什麼是分割槽？

在分散式系統中，不同的節點分佈在不同的子網路中，由於一些特殊的原因，這些子節點之間出現了網路不通的狀態，但他們的內部子網路是正常的。從而導致了整個系統的環境被切分成了若干個孤立的區域，這就是分割槽。

### 2. CAP原則論證
CAP的基本場景，網路中有兩個節點N1和N2，可以簡單的理解N1和N2分別是兩臺計算機，他們之間網路可以連通，N1中有一個應用程式A，和一個資料庫V，N2也有一個應用程式B和一個資料庫V。現在，A和B是分散式系統的兩個部分，V是分散式系統的資料儲存的兩個子資料庫。

在滿足一致性的時候，N1和N2中的資料是一樣的，V0=V0。
在滿足可用性的時候，使用者不管是請求N1或者N2，都會得到立即響應。
在滿足分割槽容錯性的情況下，N1和N2有任何一方當機，或者網路不通的時候，都不會影響N1和N2彼此之間的正常運作。

這是分散式系統正常運轉的流程，使用者向N1機器請求資料更新，程式A更新資料庫V0為V1。分散式系統將資料進行同步操作M，將V1同步的N2中V0，使得N2中的資料V0也更新為V1，N2中的資料再響應N2的請求。

根據CAP原則定義，系統的一致性、可用性和分割槽容錯性細分如下：

一致性：N1和N2的資料庫V之間的資料是否完全一樣。
可用性：N1和N2的對外部的請求能否做出正常的響應。
分割槽容錯性：N1和N2之間的網路是否互通。
這是正常運作的場景，也是理想的場景。作為一個分散式系統，它和單機系統的最大區別，就在於網路。現在假設一種極端情況，N1和N2之間的網路斷開了，我們要支援這種網路異常。相當於要滿足分割槽容錯性，能不能同時滿足一致性和可用性呢？還是說要對他們進行取捨？

假設在N1和N2之間網路斷開的時候，有使用者向N1傳送資料更新請求，那N1中的資料V0將被更新為V1。由於網路是斷開的，所以分散式系統同步操作M，所以N2中的資料依舊是V0。這個時候，有使用者向N2傳送資料讀取請求，由於資料還沒有進行同步，應用程式沒辦法立即給使用者返回最新的資料V1，怎麼辦呢？

這裡有兩種選擇：

第一：犧牲資料一致性，保證可用性。響應舊的資料V0給使用者。
第二：犧牲可用性，保證資料一致性。阻塞等待，直到網路連線恢復，資料更新操作M完成之後，再給使用者響應最新的資料V1。
這個過程，證明了要滿足分割槽容錯性的分散式系統，只能在一致性和可用性兩者中，選擇其中一個。

### 3. CAP原則權衡
透過CAP理論，我們知道無法同時滿足一致性、可用性和分割槽容錯性這三個特性，那要捨棄哪個呢？

3.1. CA without P
如果不要求P（不允許分割槽），則C（強一致性）和A（可用性）是可以保證的。但其實分割槽不是你想不想的問題，而是始終會存在，因此CA的系統更多的是允許分割槽後各子系統依然保持CA。

3.2. CP without A
如果不要求A（可用），相當於每個請求都需要在Server之間強一致，而P（分割槽）會導致同步時間無限延長，如此CP也是可以保證的。很多傳統的資料庫分散式事務都屬於這種模式。

3.3. AP wihtout C
要高可用並允許分割槽，則需放棄一致性。一旦分割槽發生，節點之間可能會失去聯絡，為了高可用，每個節點只能用本地資料提供服務，而這樣會導致全域性資料的不一致性。現在眾多的NoSQL都屬於此類。

## 小結
對於多數大型網際網路應用的場景，主機眾多、部署分散。而且現在的叢集規模越來越大，所以節點故障、網路故障是常態。這種應用一般要保證服務可用性達到N個9，即保證P和A，只有捨棄C（退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達到造成使用者流程的嚴重程度。

對於涉及到錢財這樣不能有一絲讓步的場景，C必須保證。網路發生故障寧可停止服務，這是保證CA，捨棄P。貌似這幾年國內銀行業發生了不下10起事故，但影響面不大，報到也不多，廣大群眾知道的少。還有一種是保證CP，捨棄A，例如網路故障時只讀不寫。

孰優孰劣，沒有定論，只能根據場景定奪，適合的才是最好的。

## 分散式理論(二) - BASE理論
前言
BASE理論是由eBay架構師提出的。BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模網際網路分散式系統實踐的總結，是基於CAP定律逐步演化而來。其核心思想是即使無法做到強一致性，但每個應用都可以根據自身業務特點，才用適當的方式來使系統打到最終一致性。

正文
### 1. CAP的3選2偽命題
實際上，不是為了P（分割槽容錯性），必須在C（一致性）和A（可用性）之間任選其一。分割槽的情況很少出現，CAP在大多時間能夠同時滿足C和A。

對於分割槽存在或者探知其影響的情況下，需要提供一種預備策略做出處理：

探知分割槽的發生；
進入顯示的分割槽模式，限制某些操作；
啟動恢復過程，恢復資料一致性，補償分割槽發生期間的錯誤。
2. BASE理論簡介
BASE理論是Basically Available(基本可用)，Soft State（軟狀態）和Eventually Consistent（最終一致性）三個短語的縮寫。

其核心思想是：

既是無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

### 3. BASE理論的內容
基本可用（Basically Available）
軟狀態（Soft State）
最終一致性（Eventually Consistent）
下面展開討論：

#### 3.1. 基本可用
什麼是基本可用呢？假設系統，出現了不可預知的故障，但還是能用，相比較正常的系統而言：

響應時間上的損失：正常情況下的搜尋引擎0.5秒即返回給使用者結果，而基本可用的搜尋引擎可以在2秒作用返回結果。

功能上的損失：在一個電商網站上，正常情況下，使用者可以順利完成每一筆訂單。但是到了大促期間，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

#### 3.2. 軟狀態
什麼是軟狀態呢？相對於原子性而言，要求多個節點的資料副本都是一致的，這是一種“硬狀態”。

軟狀態指的是：允許系統中的資料存在中間狀態，並認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的資料副本存在資料延時。

#### 3.3. 最終一致性
上面說軟狀態，然後不可能一直是軟狀態，必須有個時間期限。在期限過後，應當保證所有副本保持資料一致性，從而達到資料的最終一致性。這個時間期限取決於網路延時、系統負載、資料複製方案設計等等因素。

而在實際工程實踐中，最終一致性分為5種：

3.3.1. 因果一致性（Causal consistency）

因果一致性指的是：如果節點A在更新完某個資料後通知了節點B，那麼節點B之後對該資料的訪問和修改都是基於A更新後的值。於此同時，和節點A無因果關係的節點C的資料訪問則沒有這樣的限制。

3.3.2. 讀己之所寫（Read your writes）

讀己之所寫指的是：節點A更新一個資料後，它自身總是能訪問到自身更新過的最新值，而不會看到舊值。其實也算一種因果一致性。

3.3.3. 會話一致性（Session consistency）

會話一致性將對系統資料的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現 “讀己之所寫” 的一致性，也就是說，執行更新操作之後，客戶端能夠在同一個會話中始終讀取到該資料項的最新值。

3.3.4. 單調讀一致性（Monotonic read consistency）

單調讀一致性指的是：如果一個節點從系統中讀取出一個資料項的某個值後，那麼系統對於該節點後續的任何資料訪問都不應該返回更舊的值。

3.3.5. 單調寫一致性（Monotonic write consistency）

單調寫一致性指的是：一個系統要能夠保證來自同一個節點的寫操作被順序的執行。

在實際的實踐中，這5種系統往往會結合使用，以構建一個具有最終一致性的分散式系統。

實際上，不只是分散式系統使用最終一致性，關係型資料庫在某個功能上，也是使用最終一致性的。比如備份，資料庫的複製過程是需要時間的，這個複製過程中，業務讀取到的值就是舊的。當然，最終還是達成了資料一致性。這也算是一個最終一致性的經典案例。

### 更具體的分散式問題
#### 分散式事務
指事務的操作位於不同的節點上，需要保證事務的 AICD 特性。例如在下單場景下，庫存和訂單如果不在同一個節點上，就需要涉及分散式事務。

本地訊息
1. 原理
本地訊息表與業務資料表處於同一個資料庫中，這樣就能利用本地事務來保證在對這兩個表的操作滿足事務特性。

在分散式事務操作的一方，它完成寫業務資料的操作之後向本地訊息表傳送一個訊息，本地事務能保證這個訊息一定會被寫入本地訊息表中。
之後將本地訊息表中的訊息轉發到 Kafka 等訊息佇列（MQ）中，如果轉發成功則將訊息從本地訊息表中刪除，否則繼續重新轉發。
在分散式事務操作的另一方從訊息佇列中讀取一個訊息，並執行訊息中的操作。

2. 分析
本地訊息表利用了本地事務來實現分散式事務，並且使用了訊息佇列來保證最終一致性。

兩階段提交協議
2PC

#### 二、分散式鎖
可以使用 Java 提供的內建鎖來實現程式同步：由 JVM 實現的 synchronized 和 JDK 提供的 Lock。但是在分散式場景下，需要同步的程式可能位於不同的節點上，那麼就需要使用分散式鎖來同步。

原理
鎖可以有阻塞鎖和樂觀鎖兩種實現方式，這裡主要探討阻塞鎖實現。阻塞鎖通常使用互斥量來實現，互斥量為 1 表示有其它程式在使用鎖，此時處於鎖定狀態，互斥量為 0 表示未鎖定狀態。1 和 0 可以用一個整型值來儲存，也可以用某個資料存在或者不存在來儲存，某個資料存在表示互斥量為 1，也就是鎖定狀態。

實現

1. 資料庫的唯一索引
當想要獲得鎖時，就向表中插入一條記錄，釋放鎖時就刪除這條記錄。唯一索引可以保證該記錄只被插入一次，那麼就可以用這個記錄是否存在來判斷是否存於鎖定狀態。

這種方式存在以下幾個問題：

鎖沒有失效時間，解鎖失敗會導致死鎖，其他執行緒無法再獲得鎖。
只能是非阻塞鎖，插入失敗直接就報錯了，無法重試。
不可重入，同一執行緒在沒有釋放鎖之前無法再獲得鎖。
2. Redis 的 SETNX 指令
使用 SETNX（set if not exist）指令插入一個鍵值對，如果 Key 已經存在，那麼會返回 False，否則插入成功並返回 True。

SETNX 指令和資料庫的唯一索引類似，可以保證只存在一個 Key 的鍵值對，可以用一個 Key 的鍵值對是否存在來判斷是否存於鎖定狀態。

EXPIRE 指令可以為一個鍵值對設定一個過期時間，從而避免了死鎖的發生。

3. Redis 的 RedLock 演算法
使用了多個 Redis 例項來實現分散式鎖，這是為了保證在發生單點故障時仍然可用。

嘗試從 N 個相互獨立 Redis 例項獲取鎖，如果一個例項不可用，應該儘快嘗試下一個。
計算獲取鎖消耗的時間，只有當這個時間小於鎖的過期時間，並且從大多數（N/2+1）例項上獲取了鎖，那麼就認為鎖獲取成功了。
如果鎖獲取失敗，會到每個例項上釋放鎖。
4. Zookeeper 的有序節點
Zookeeper 是一個為分散式應用提供一致服務的軟體，例如配置管理、分散式協同以及命名的中心化等，這些都是分散式系統中非常底層而且是必不可少的基本功能，但是如果自己實現這些功能而且要達到高吞吐、低延遲同時還要保持一致性和可用性，實際上非常困難。

（一）抽象模型

Zookeeper 提供了一種樹形結構級的名稱空間，/app1/p_1 節點表示它的父節點為 /app1。

（二）節點型別

永久節點：不會因為會話結束或者超時而消失；
臨時節點：如果會話結束或者超時就會消失；
有序節點：會在節點名的後面加一個數字字尾，並且是有序的，例如生成的有序節點為 /lock/node-0000000000，它的下一個有序節點則為 /lock/node-0000000001，依次類推。

（三）監聽器

為一個節點註冊監聽器，在節點狀態發生改變時，會給客戶端傳送訊息。

（四）分散式鎖實現

建立一個鎖目錄 /lock；
在 /lock 下建立臨時的且有序的子節點，第一個客戶端對應的子節點為 /lock/lock-0000000000，第二個為 /lock/lock-0000000001，以此類推；
客戶端獲取 /lock 下的子節點列表，判斷自己建立的子節點是否為當前子節點列表中序號最小的子節點，如果是則認為獲得鎖；否則監聽自己的前一個子節點，獲得子節點的變更通知後重復此步驟直至獲得鎖；
執行業務程式碼，完成後，刪除對應的子節點。

（五）會話超時

如果一個已經獲得鎖的會話超時了，因為建立的是臨時節點，所以該會話對應的臨時節點會被刪除，其它會話就可以獲得鎖了。可以看到，Zookeeper 分散式鎖不會出現資料庫的唯一索引實現分散式鎖的死鎖問題。

（六）羊群效應

一個節點未獲得鎖，需要監聽自己的前一個子節點，這是因為如果監聽所有的子節點，那麼任意一個子節點狀態改變，其它所有子節點都會收到通知（羊群效應），而我們只希望它的後一個子節點收到通知。

#### 三、分散式 Session
在分散式場景下，一個使用者的 Session 如果只儲存在一個伺服器上，那麼當負載均衡器把使用者的下一個請求轉發到另一個伺服器上，該伺服器沒有使用者的 Session，就可能導致使用者需要重新進行登入等操作。

1. Sticky Sessions
需要配置負載均衡器，使得一個使用者的所有請求都路由到一個伺服器節點上，這樣就可以把使用者的 Session 存放在該伺服器節點中。

缺點：當伺服器節點當機時，將丟失該伺服器節點上的所有 Session。

2. Session Replication
在伺服器節點之間進行 Session 同步操作，這樣的話使用者可以訪問任何一個伺服器節點。

缺點：需要更好的伺服器硬體條件；需要對伺服器進行配置。

3. Persistent DataStore
將 Session 資訊持久化到一個資料庫中。

缺點：有可能需要去實現存取 Session 的程式碼。

4. In-Memory DataStore
可以使用 Redis 和 Memcached 這種記憶體型資料庫對 Session 進行儲存，可以大大提高 Session 的讀寫效率。記憶體型資料庫同樣可以持久化資料到磁碟中來保證資料的安全性。

#### 四、負載均衡
演算法
1. 輪詢（Round Robin）
輪詢演算法把每個請求輪流傳送到每個伺服器上。下圖中，一共有 6 個客戶端產生了 6 個請求，這 6 個請求按 (1, 2, 3, 4, 5, 6) 的順序傳送。最後，(1, 3, 5) 的請求會被髮送到伺服器 1，(2, 4, 6) 的請求會被髮送到伺服器 2。

該演算法比較適合每個伺服器的效能差不多的場景，如果有效能存在差異的情況下，那麼效能較差的伺服器可能無法承擔過大的負載（下圖的 Server 2）。

2. 加權輪詢（Weighted Round Robbin）
加權輪詢是在輪詢的基礎上，根據伺服器的效能差異，為伺服器賦予一定的權值。例如下圖中，伺服器 1 被賦予的權值為 5，伺服器 2 被賦予的權值為 1，那麼 (1, 2, 3, 4, 5) 請求會被髮送到伺服器 1，(6) 請求會被髮送到伺服器 2。

3. 最少連線（least Connections）
由於每個請求的連線時間不一樣，使用輪詢或者加權輪詢演算法的話，可能會讓一臺伺服器當前連線數過大，而另一臺伺服器的連線過小，造成負載不均衡。例如下圖中，(1, 3, 5) 請求會被髮送到伺服器 1，但是 (1, 3) 很快就斷開連線，此時只有 (5) 請求連線伺服器 1；(2, 4, 6) 請求被髮送到伺服器 2，只有 (2) 的連線斷開。該系統繼續執行時，伺服器 2 會承擔過大的負載。

最少連線演算法就是將請求傳送給當前最少連線數的伺服器上。例如下圖中，伺服器 1 當前連線數最小，那麼新到來的請求 6 就會被髮送到伺服器 1 上。

4. 加權最少連線（Weighted Least Connection）
在最少連線的基礎上，根據伺服器的效能為每臺伺服器分配權重，再根據權重計算出每臺伺服器能處理的連線數。

5. 隨機演算法（Random）
把請求隨機傳送到伺服器上。和輪詢演算法類似，該演算法比較適合伺服器效能差不多的場景。

6. 源地址雜湊法 (IP Hash)
源地址雜湊透過對客戶端 IP 雜湊計算得到的一個數值，用該數值對伺服器數量進行取模運算，取模結果便是目標伺服器的序號。

優點：保證同一 IP 的客戶端都會被 hash 到同一臺伺服器上。
缺點：不利於叢集擴充套件，後臺伺服器數量變更都會影響 hash 結果。可以採用一致性 Hash 改進。

實現
1. HTTP 重定向
HTTP 重定向負載均衡伺服器收到 HTTP 請求之後會返回伺服器的地址，並將該地址寫入 HTTP 重定向響應中返回給瀏覽器，瀏覽器收到後需要再次傳送請求。

缺點：

使用者訪問的延遲會增加；
如果負載均衡器當機，就無法訪問該站點。

2. DNS 重定向
使用 DNS 作為負載均衡器，根據負載情況返回不同伺服器的 IP 地址。大型網站基本使用了這種方式做為第一級負載均衡手段，然後在內部使用其它方式做第二級負載均衡。

缺點：

DNS 查詢表可能會被客戶端快取起來，那麼之後的所有請求都會被重定向到同一個伺服器。

3. 修改 MAC 地址
使用 LVS（Linux Virtual Server）這種鏈路層負載均衡器，根據負載情況修改請求的 MAC 地址。

4. 修改 IP 地址
在網路層修改請求的目的 IP 地址。

5. 代理自動配置
正向代理與反向代理的區別：

正向代理：發生在客戶端，是由使用者主動發起的。比如，客戶端透過主動訪問代理伺服器，讓代理伺服器獲得需要的外網資料，然後轉發回客戶端。
反向代理：發生在伺服器端，使用者不知道代理的存在。
PAC 伺服器是用來判斷一個請求是否要經過代理。

#### 高可用之“腦裂”

在涉及到高可用性時，經常會聽到”腦裂“，到底啥是”腦裂“？

一句話：當兩（多）個節點同時認為自已是唯一處於活動狀態的伺服器從而出現爭用資源的情況，這種爭用資源的場景即是所謂的“腦裂”（split-brain）或”區間叢集“（partitioned cluster）。

--------------

HeartBeat原理：

HeartBeat執行於備用主機上的Heartbeat可以透過乙太網連線檢測主伺服器的執行狀態，一旦其無法檢測到主伺服器的"心跳"則自動接管主伺服器的資源。通常情況下，主、備伺服器間的心跳連線是一個獨立的物理連線，這個連線可以是序列線纜、一個由"交叉線"實現的乙太網連線。Heartbeat甚至可同時透過多個物理連線檢測主伺服器的工作狀態，而其只要能透過其中一個連線收到主伺服器處於活動狀態的資訊，就會認為主伺服器處於正常狀態。從實踐經驗的角度來說，建議為Heartbeat配置多條獨立的物理連線，以避免Heartbeat通訊線路本身存在單點故障。

--------------

在“雙機熱備”高可用（HA）系統中，當聯絡2個節點的“心跳線”斷開時，本來為一整體、動作協調的HA系統，就分裂成為2個獨立的個體。由於相互失去了聯絡，都以為是對方出了故障，2個節點上的HA軟體像“裂腦人”一樣，“本能”地爭搶“共享資源”、爭起“應用服務”，就會發生嚴重後果：或者共享資源被瓜分、2邊“服務”都起不來了；或者2邊“服務”都起來了，但同時讀寫“共享儲存”，導致資料損壞（常見如資料庫輪詢著的聯機日誌出錯）。
      
執行於備用主機上的Heartbeat可以透過乙太網連線檢測主伺服器的執行狀態，一旦其無法檢測到主伺服器的“心跳”則自動接管主伺服器的資源。通常情況下，主、備伺服器間的心跳連線是一個獨立的物理連線，這個連線可以是序列線纜、一個由“交叉線”實現的乙太網連線。Heartbeat甚至可同時透過多個物理連線檢測主伺服器的工作狀態，而其只要能透過其中一個連線收到主伺服器處於活動狀態的資訊，就會認為主伺服器處於正常狀態。從實踐經驗的角度來說，建議為Heartbeat配置多條獨立的物理連線，以避免Heartbeat通訊線路本身存在單點故障。

1、序列電纜：被認為是比乙太網連線安全性稍好些的連線方式，因為hacker無法透過序列連線執行諸如telnet、ssh或rsh類的程式，從而可以降低其透過已劫持的伺服器再次侵入備份伺服器的機率。但序列線纜受限於可用長度，因此主、備伺服器的距離必須非常短。
2、乙太網連線：使用此方式可以消除序列線纜的在長度方面限制，並且可以透過此連線在主備伺服器間同步檔案系統，從而減少了從正常通訊連線頻寬的佔用。

基於冗餘的角度考慮，應該在主、備伺服器使用兩個物理連線傳輸heartbeat的控制資訊；這樣可以避免在一個網路或線纜故障時導致兩個節點同時認為自已是唯一處於活動狀態的伺服器從而出現爭用資源的情況，這種爭用資源的場景即是所謂的“腦裂”（split-brain）或“partitioned cluster”。在兩個節點共享同一個物理裝置資源的情況下，腦裂會產生相當可怕的後果。

為了避免出現腦裂，可採用下面的預防措施：
新增冗餘的心跳線，例如雙線條線。儘量減少“裂腦”發生機會。
啟用磁碟鎖。正在服務一方鎖住共享磁碟，“裂腦”發生時，讓對方完全“搶不走”共享磁碟資源。但使用鎖磁碟也會有一個不小的問題，如果佔用共享盤的一方不主動“解鎖”，另一方就永遠得不到共享磁碟。現實中假如服務節點突然當機或崩潰，就不可能執行解鎖命令。後備節點也就接管不了共享資源和應用服務。於是有人在HA中設計了“智慧”鎖。即，正在服務的一方只在發現心跳線全部斷開（察覺不到對端）時才啟用磁碟鎖。平時就不上鎖了。

設定仲裁機制。例如設定參考IP（如閘道器IP），當心跳線完全斷開時，2個節點都各自ping一下 參考IP，不通則表明斷點就出在本端，不僅“心跳”、還兼對外“服務”的本端網路鏈路斷了，即使啟動（或繼續）應用服務也沒有用了，那就主動放棄競爭，讓能夠ping通參考IP的一端去起服務。更保險一些，ping不通參考IP的一方乾脆就自我重啟，以徹底釋放有可能還佔用著的那些共享資源。

搞懂分散式技術1：分散式系統的一些基本概念

相關文章