分佈式系統基礎的基本概念

前言

最近在工做之餘看了一些分佈式系統的博客和一點書本知識，從理論上了解了一些分佈式系統的基本知識。給我最深的感受就是全部的軟件技術和架構都是隨着業務的不斷髮展和底層技術的更新纔有機會一步步的深刻。特別是學習cap和base時，瞭解到分佈式事務與傳統DB事務ACID的區別（其實分佈式事務和傳統DB事務不是一個層面的東西可是感受思想上仍是有一些共同之處的）。如今的分佈式系統也都是由最初的集中式系統一步步發展過來的。

在這裏總結一下最近學的一些基礎吧~~

集中式與分佈式

很容易理解：

• 集中式：一臺或多態住計算機組成中心節點，數據集中存儲於中心節點上，而且系統全部的業務單元都集中部署在這個中心節點上，並在其上處理系統全部功能。
  • 其實個人理解就是說全部的業務和邏輯都在這個中心節點上完成，其餘的客戶端就負責輸入和輸出就能夠了。
• 分佈式：分佈式系統是一個硬件或軟件組件分佈在不一樣的網絡計算機上，彼此之間僅僅經過消息傳遞進行通訊和協調的系統。
  • 這是經典的分佈式著做《分佈式系統概念與設計》中的定義。其實在個人理解裏，就是把一個大的系統拆分紅不少個業務模塊，並部署在多臺網絡計算機上。就是把集中式的中心節點拆分爲多個節點去完成單箇中心節點的工做。
  • 分佈式系統的幾個特色：
    • 分佈性：分佈式系統的多個節點或者說多個模塊在空間上是隨意分佈的。
    • 對等性：系統模塊的多個節點沒有主從之分。其實這裏我理解的沒有主從之分並非說完徹底全沒有主節點和從節點，而是在任什麼時候候，若是有主節點，且主節點發生了不可用的狀況下，能有必定的方法讓別的節點去取代它，這樣的話系統中就沒有一個節點是所謂的特殊的，而全部的節點都是同樣的能夠互相替換的，這某種程度上應該就是分佈式系統中的副本的概念。而副本的話應該是分爲服務副本和數據副本的，由於服務和數據均可能會出現不可用的現象，因此必需要有副本去保持系統可用。
    • 併發性：很好理解，分佈式系統中程序的併發性操做和對數據的併發訪問是很常見的。其實也由於併發性，如何作到高效準確也就成爲了分佈式系統的一個難題。
    • 缺少全局時鐘：一樣的，由於分佈式系統部署在多臺網絡計算機上，因爲網絡的存在很難定義事務的前後順序。也就是說分佈式系統缺乏全局的始終順序控制。以前在學習的時候看到過度布式全局惟一ID能夠解決部分問題，以後能夠再看看總結一下。我目前瞭解的分佈式全局ID的生成有UUID和SNOWFLAKE算法，可是具體的底層還不是很清楚。
    • 故障老是會發生：分佈式系統相較集中式系統更容易發生故障，且在系統設計時考慮到的西昌在實際中是必定會發生的，因此必需要解決。（固然，若是是業務或者需求容許的能夠考慮必定程度的放寬。）

分佈式系統的問題

進程或節點之間的通訊異常

其實如在Zookeeper學習（一）中描述的同樣，致使分佈式系統通訊異常的根本罪魁禍首就在於網絡！由於網絡自己就是不可靠的。與單機系統不一樣的是，因爲分佈式系統中網絡通訊的存在，會致使系統之間的調用存在相對較大的延遲（可達到內存訪問延遲的百倍）。並且網絡隨時會出現波動的狀況，所以消息丟失和延遲會變得很廣泛。

網絡分區

因爲網絡發生異常，致使分佈式系統中部分節點之間的網絡延時不斷增大，致使全部節點中只有部分節點能互相正常通訊，而其餘的不能。這其實就是所謂的「腦裂」。最差的狀況甚至會出現多個局部小集羣的狀況。

三態

三態即成功，失敗，超時。

單機系統中調用服務成功失敗很明顯，可是在分佈式系統中很明顯，由於存在網絡的因素，在調用服務失敗的狀況下可能並不必定是由於沒有調用服務成功。

• 調用服務確實沒有成功，網絡請求沒有發送到接收方。
• 調用服務成功，可是在返回響應時出現了消息丟失。

這時候就須要針對不一樣的業務進行處理了。結合咱們以前作的業務，咱們的系統中處理辦法是回寫時會讓服務發送接收OK的標誌，若是沒有收到OK，那麼就會一直髮，由於回寫的接收方在邏輯裏支持刪除不存在的元素（其實就是不刪），只有收到了OK纔會把回寫的內容從Redis裏刪掉。這樣就保證了回寫必定會成功。

節點故障

很好理解，每一臺機器都是會出問題的，如何保證在部分節點出現問題時整個系統仍然可用，是分佈式系統裏永恆不變的問題！

從ACID到CAP/BASE

ACID

ACID是傳統數據庫中事務的特徵，即原子性，一致性，隔離性和持久性。

• 原子性：指事務必須是一個原子的操做單元。也就是說事務要麼所有執行成功，要麼不執行，若是執行過程當中失敗那麼就回滾到最初的狀態。
• 一致性：事務的執行不能夠破壞數據庫數據的完整性和一致性。也就是說事務在執行先後，數據庫都必須處於一致性的狀態。其實當初學數據庫的時候一開始並不太理解爲何既然有原子性了，事務要麼執行完要麼不執行，爲啥還會出現一致性的問題。後來才知道是由於多個事務併發執行的時候，很容易出現a事務作了x=1的操做，而後b事務又作了x=0的操做，就至關於b事務直接把a事務的操做給覆蓋了，這就破壞了數據庫的一致性。
• 隔離性：併發壞境中，事務是互相隔離的，一個事物的執行不能被其餘事務干擾。這就是爲了防止上面說的一致性的問題。而數據庫裏規定了4個隔離級別：
  • 讀未提交：會出現髒讀，不可重複讀，幻讀問題。隔離級別最低。
  • 讀提交：解決髒讀，但不可重複讀，幻讀仍是會有。
  • 可重複讀：會存在幻讀問題，但前兩個問題不會有。
  • 序列化：至關於事務順序執行，不會有上述問題，但併發程度最低，效率也最低。
  • mysql裏利用了MVCC和鎖的機制實現了隔離級別，可是這部分我也只是知道個大概，底層的實現原理尚未來得及深究，以前看了幾篇博客記錄下，以後深刻學習Mysql的時候這部分要深刻學習下。
  • Mysql數據庫事務的隔離級別和鎖的實現原理分析
  • [MySQL的四種事務隔離級別](https://www.cnblogs.com/huanongying/p/7021555.html)
  • MySQL事務隔離級別的實現原理
  • Mysql鎖詳解
• 持久性：一個事物一旦提交，它對數據庫中對應數據的狀態變動應該是永久性的。也就是說事務一旦成功結束，那麼它對數據庫所作的更新必須被永久保存下來。

CAP

CAP理論是針對分佈式事務的一套理論。所謂分佈式事務就是事物的參與者，支持十五的服務器，資源服務器以及事務管理器分別位於分佈式系統的不一樣節點上。一般一個分佈式事務會涉及對多個數據源或業務系統的操做。

CAP指的是一個分佈式系統不可能同時知足一致性，可用性和分區容錯性這三個基本要求，最多隻能同時知足其中的兩項。

• 一致性：在分佈式環境中，一致性是指數據在多個副本之間是否可以保持一致的特性。也就是說，當一個系統在數據一致的狀態下執行更新操做後，應該保證系統的數據仍然出於一致的狀態。
  • 分佈式系統裏，若是數據副本分佈在不一樣分佈式節點上，若對第一個節點的數據進行了更新操做而且更新成功後，卻沒有使得第二個節點上的數據獲得相應更新，那麼若是系統是從第二個節點上讀的數據，那麼就會讀到老數據，就出現了不一致的狀況。
  • 分佈式系統的一致性和單機事務的一致性有很大的區別，以前本身一直能感受到不同可是很難用理論化的語言描述出來，ACID的C與CAP的C區別這篇博客介紹的很是很是好，能夠看！！！
• 可用性：系統提供的服務必須一直處於可用的狀態，對於用戶的每個操做請求老是可以在有限的時間內返回結果。有限的時間某種程度上指的是系統的反應時間不能夠超過用戶的忍耐程度，返回結果則值得是系統對於用戶的請求必需要返回一個能夠接受的結果。
• 分區容錯性：分佈式系統由於是依賴網絡的，因此不免會出現遇到網絡分區故障的時候，而這個時候仍然要保證能對外提供一致性和可用性的服務，除非整個網絡癱瘓。
  • 以前我一直分不清可用性和分區容錯性的區別，感受只要高可用了不就知足了容錯性了麼。。。可是參考了不少資料以後才發現分區容錯性和可用性，一致性的關係更像是因果（不必定準確）的關係。正是由於分區的存在，因此在須要解決一致性和可用性的問題。
  • CAP理論的P知乎上的這個回答是我認爲解釋的最通俗易懂的一篇。
  • CAP裏的P ，CAP, ACID ，分佈式系統設計系列 -- 基本原理及高可用策略， 分佈式CAP理論的理解， 這幾篇都很好，能夠參考。

BASE

BASE = Basically Available + Soft state + Eventually consistent。

• 基本可用：分佈式系統出現不可預知故障時，容許損失部分可用性。
  • 響應時間損失。0.5s-->2s
  • 功能損失。雙十一淘寶扛不住了把評論服務先降級掉。
• 弱狀態：容許系統數據存在中間狀態，並認爲該中間狀態的存在不會影響系統總體可用性，即容許系統在不一樣節點的數據副本之間進行數據同步的過程存在延時。
• 最終一致性：系統中全部數據副本，在通過一段時間同步後，最終能打到一個一致的狀態。
  • 最終一致性其實是一種特殊的弱一致性。
  • 因果一致性（Casual Consistency）：A進程更新完後通知B，那麼B對該數據項的訪問應該能獲取到A更新後的最新值，且B若是要更新該數據，必須基於進程A更新後的值。
  • 讀己寫（Read you writes）：A更新一個數據向後，本身老是能訪問到更新過的最新值。是一種特殊的因果一致性。
  • 會話一致性（Session Consistency）：對系統數據的訪問過程狂頂在一個繪畫中，系統能保證在同一個有效的會話中實現Read your writes。即更新操做後，客戶端能在同一個繪畫中適中讀取到該數據項的最新值。
  • 單調讀一致性（Monotonic read consistency）：若是一個進程從系統中讀取出一個數據項的某一個值後，那麼系統對於該進程後續的任何數據訪問都不該該返回更舊的值。
  • 單調寫一致性（Monotonic write consistency）：一個系統須要可以保證同一個進程的寫操做被順序執行。
  • 數據庫的主備通常都採用最終一致性的策略。有兩種方式去實現，即同步和異步。同步的方式就是事務完成後主備之間數據就會進行同步，異步的方式備數據庫的更新會有必定時間的延遲，可是效率會更高一些。