分布式系统的一些基本概念
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來保存吧！例如一般把session存到redis里面
?
?
?
認識分布式架構
認識分布式架構?隨著計算機系統規模變得越來越大，將所有的業務單元集中部署在一個或若干個大型機上的體系結構，已經越來越不能滿足當今計算機系統，尤其是大型互聯網系統的快速發展，各種靈活多變的系統架構模型層出不窮。分布式的處理方式越來越受到業界的青睞——計算機系統正在經歷一場前所未有的從集中式向分布式架構的變革。
集中式與分布式
集中式系統
所謂的集中式系統就是指由一臺或多臺主計算機組成中心節點，數據集中存儲于這個中心節點中，并且整個系統的所有業務單元都集中部署在這個中心節點上，系統的所有功能均由其集中處理。
集中式系統的最大的特點就是部署結構非常簡單，底層一般采用從IBM、HP等廠商購買到的昂貴的大型主機。因此無需考慮如何對服務進行多節點的部署，也就不用考慮各節點之間的分布式協作問題。但是，由于采用單機部署，很可能帶來系統大而復雜、難于維護、發生單點故障（單個點發生故障的時候會波及到整個系統或者網絡，從而導致整個系統或者網絡的癱瘓）、擴展性差等問題。
分布式系統
分布式系統是一個硬件或軟件組件分布在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。簡單來說就是一群獨立計算機集合共同對外提供服務，但是對于系統的用戶來說，就像是一臺計算機在提供服務一樣。分布式意味著可以采用更多的普通計算機（相對于昂貴的大型機）組成分布式集群對外提供服務。計算機越多，CPU、內存、存儲資源等也就越多，能夠處理的并發訪問量也就越大。
從分布式系統的概念中我們知道，各個主機之間通信和協調主要通過網絡進行，所以分布式系統中的計算機在空間上幾乎沒有任何限制，這些計算機可能被放在不同的機柜上，也可能被部署在不同的機房中，還可能在不同的城市中，對于大型的網站甚至可能分布在不同的國家和地區。但是，無論空間上如何分布，一個標準的分布式系統應該具有以下幾個主要特征：
主要特征
分布性
分布式系統中的多臺計算機之間在空間位置上可以隨意分布，同時，機器的分布情況也會隨時變動。
對等性
分布式系統中的計算機沒有主／從之分，即沒有控制整個系統的主機，也沒有被控制的從機，組成分布式系統的所有計算機節點都是對等的。副本（Replica）是分布式系統最常見的概念之一，指的是分布式系統對數據和服務提供的一種冗余方式。在常見的分布式系統中，為了對外提供高可用的服務，我們往往會對數據和服務進行副本處理。數據副本是指在不同節點上持久化同一份數據，當某一個節點上存儲的數據丟失時，可以從副本上讀取該數據，這是解決分布式系統數據丟失問題最為有效的手段。另一類副本是服務副本，指多個節點提供同樣的服務，每個節點都有能力接收來自外部的請求并進行相應的處理。
并發性
在一個計算機網絡中，程序運行過程的并發性操作是非常常見的行為。例如同一個分布式系統中的多個節點，可能會并發地操作一些共享的資源，如何準確并高效地協調分布式并發操作也成為了分布式系統架構與設計中最大的挑戰之一。
缺乏全局時鐘
在分布式系統中，很難定義兩個事件究竟誰先誰后，原因就是因為分布式系統缺乏一個全局的時鐘序列控制。
故障總是會發生
組成分布式系統的所有計算機，都有可能發生任何形式的故障。除非需求指標允許，在系統設計時不能放過任何異常情況。
分布式系統面臨的問題
通信異常
分布式系統需要在各個節點之間進行網絡通信，因此網絡通信都會伴隨著網絡不可用的風險或是系統不可用都會導致最終分布式系統無法順利完成一次網絡通信。另外，即使分布式系統各節點之間的網絡通信能夠正常進行，其延時也會遠大于單機操作，會影響消息的收發的過程，因此消息丟失和消息延遲變得非常普遍。
網絡分區
當網絡由于發生異常情況，導致分布式系統中部分節點之間的網絡延時不斷增大，最終導致組成分布式系統的所有節點中，只有部分節點之間能夠進行正常通信，而另一些節點則不能——我們將這個現象稱為網絡分區，就是俗稱的“腦裂”。當網絡分區出現時，分布式系統會出現局部小集群，在極端情況下，這些局部小集群會獨立完成原本需要整個分布式才能完成的功能，這就對分布式一致性提出類非常大的挑戰。
三態
分布式系統的每一次請求與響應，存在特有的“三態”概念，即成功、失敗與超時。當出現超時現象時，網絡通信的發起方是無法確定當前請求是否被成功處理的。
節點故障
節點故障則是分布式環境下另一個比較常見的問題，指的是組成分布式系統的服務器節點出現的宕機或“僵死”現象。
?
?
?
分布式理論(一) - CAP定理
前言?CAP原則又稱CAP定理，指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性）這三個基本需求，最多只能同時滿足其中的2個。
?
1.CAP原則簡介
Consistency（一致性）?指數據在多個副本之間能夠保持一致的特性（嚴格的一致性）?Availability（可用性）?指系統提供的服務必須一直處于可用的狀態，每次請求都能獲取到非錯的響應（不保證獲取的數據為最新數據）?Partition tolerance（分區容錯性）?分布式系統在遇到任何網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務，除非整個網絡環境都發生了故障
什么是分區？
在分布式系統中，不同的節點分布在不同的子網絡中，由于一些特殊的原因，這些子節點之間出現了網絡不通的狀態，但他們的內部子網絡是正常的。從而導致了整個系統的環境被切分成了若干個孤立的區域，這就是分區。
?
2.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?要高可用并允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性?，F在眾多的NoSQL都屬于此類。
3.小結
對于多數大型互聯網應用的場景，主機眾多、部署分散。而且現在的集群規模越來越大，所以節點故障、網絡故障是常態。這種應用一般要保證服務可用性達到N個9，即保證P和A，只有舍棄C（退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達到造成用戶流程的嚴重程度。
對于涉及到錢財這樣不能有一絲讓步的場景，C必須保證。網絡發生故障寧可停止服務，這是保證CA，舍棄P。貌似這幾年國內銀行業發生了不下10起事故，但影響面不大，報到也不多，廣大群眾知道的少。還有一種是保證CP，舍棄A，例如網絡故障時只讀不寫。
孰優孰劣，沒有定論，只能根據場景定奪，適合的才是最好的。
?
分布式理論(二) - BASE理論
前言?BASE理論是由eBay架構師提出的。BASE是對CAP中一致性和可用性權衡的結果，其來源于對大規?；ヂ摼W分布式系統實踐的總結，是基于CAP定律逐步演化而來。其核心思想是即使無法做到強一致性，但每個應用都可以根據自身業務特點，用適當的方式來使系統達到最終一致性。
正文
CAP的3選2偽命題?實際上，不是為了P（分區容錯性），必須在C（一致性）和A（可用性）之間任選其一。分區的情況很少出現，CAP在大多時間能夠同時滿足C和A。
對于分區存在或者探知其影響的情況下，需要提供一種預備策略做出處理：
探知分區的發生；?進入顯示的分區模式，限制某些操作；?啟動恢復過程，恢復數據一致性，補償分區發生期間的錯誤。
BASE理論簡介?BASE理論是Basically Available(基本可用)，Soft State（軟狀態）和Eventually Consistent（最終一致性）三個短語的縮寫。
其核心思想是：
既是無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。
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種系統往往會結合使用，以構建一個具有最終一致性的分布式系統。
實際上，不只是分布式系統使用最終一致性，關系型數據庫在某個功能上，也是使用最終一致性的。比如備份，數據庫的復制過程是需要時間的，這個復制過程中，業務讀取到的值就是舊的。當然，最終還是達成了數據一致性。這也算是一個最終一致性的經典案例。
?
總結
以上是生活随笔為你收集整理的分布式系统的一些基本概念的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式系统概念
- 下一篇： 大规模分布式系统概念介绍