web分布式系統的基本概念是什么

這篇文章主要講解了“web分布式系統的基本概念是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“web分布式系統的基本概念是什么”吧！

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。

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

探知分區的發生；
進入顯示的分區模式，限制某些操作；
啟動恢復過程，恢復數據一致性，補償分區發生期間的錯誤。

1. 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）中，如果轉發成功則將消息從本地消息表中刪除，否則繼續重新轉發。
在分布式事務操作的另一方從消息隊列中讀取一個消息，并執行消息中的操作。

1. 分析
   本地消息表利用了本地事務來實現分布式事務，并且使用了消息隊列來保證最終一致性。

兩階段提交協議
2PC

二、分布式鎖

可以使用 Java 提供的內置鎖來實現進程同步：由 JVM 實現的 synchronized 和 JDK 提供的 Lock。但是在分布式場景下，需要同步的進程可能位于不同的節點上，那么就需要使用分布式鎖來同步。

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

實現

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

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

鎖沒有失效時間，解鎖失敗會導致死鎖，其他線程無法再獲得鎖。
只能是非阻塞鎖，插入失敗直接就報錯了，無法重試。
不可重入，同一線程在沒有釋放鎖之前無法再獲得鎖。

1. Redis 的 SETNX 指令
   使用 SETNX（set if not exist）指令插入一個鍵值對，如果 Key 已經存在，那么會返回 False，否則插入成功并返回 True。

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

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

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

嘗試從 N 個相互獨立 Redis 實例獲取鎖，如果一個實例不可用，應該盡快嘗試下一個。
計算獲取鎖消耗的時間，只有當這個時間小于鎖的過期時間，并且從大多數（N/2+1）實例上獲取了鎖，那么就認為鎖獲取成功了。
如果鎖獲取失敗，會到每個實例上釋放鎖。

1. 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。

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

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

1. Persistent DataStore
   將 Session 信息持久化到一個數據庫中。

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

1. 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）。

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

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

最少連接算法就是將請求發送給當前最少連接數的服務器上。例如下圖中，服務器 1 當前連接數最小，那么新到來的請求 6 就會被發送到服務器 1 上。

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

1. 隨機算法（Random）
   把請求隨機發送到服務器上。和輪詢算法類似，該算法比較適合服務器性能差不多的場景。

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

優點：保證同一 IP 的客戶端都會被 hash 到同一臺服務器上。
缺點：不利于集群擴展，后臺服務器數量變更都會影響 hash 結果。可以采用一致性 Hash 改進。

實現

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

缺點：

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

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

缺點：

DNS 查找表可能會被客戶端緩存起來，那么之后的所有請求都會被重定向到同一個服務器。

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

1. 修改 IP 地址
   在網絡層修改請求的目的 IP 地址。

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

正向代理：發生在客戶端，是由用戶主動發起的。比如，客戶端通過主動訪問代理服務器，讓代理服務器獲得需要的外網數據，然后轉發回客戶端。
反向代理：發生在服務器端，用戶不知道代理的存在。
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的一方干脆就自我重啟，以徹底釋放有可能還占用著的那些共享資源。

感謝各位的閱讀，以上就是“web分布式系統的基本概念是什么”的內容了，經過本文的學習后，相信大家對web分布式系統的基本概念是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！