分佈式系統的經典基礎理論

歷史文章推薦：

多是最漂亮的Spring事務管理詳解

面試中關於Java虛擬機（jvm）的問題看這篇就夠了

Java NIO 概覽

關於分佈式計算的一些概念

分佈式系統設計理念

分佈式系統架構的第一原則是不要分佈！這句話看似矛盾實則揭露了分佈式系統的不少特徵。

分佈式系統的目標與要素

分佈式系統的目標是提高系統的總體性能和吞吐量另外還要儘可能保證分佈式系統的容錯性（假如增長10臺服務器才達到單機運行效果2倍左右的性能，那麼這個分佈式系統就根本沒有存在的意義）。

即便採用了分佈式系統，咱們也要盡力運用併發編程、高性能網絡框架等等手段提高單機上的程序性能。

分佈式系統設計兩大思路：中心化和去中心化

1）中心化設計：

• 兩個角色： 中心化的設計思想很簡單，分佈式集羣中的節點機器按照角色分工，大致上分爲兩種角色： 「領導」 和 「幹活的」
• 角色職責： 「領導」一般負責分發任務並監督「幹活的」，發現誰太閒了，就想發設法地給其安排新任務，確保沒有一個「幹活的」可以偷懶，若是「領導」發現某個「幹活的」由於勞累過分而病倒了，則是不會考慮先嚐試「醫治」他的，而是一腳踢出去，而後把他的任務分給其餘人。其中微服務架構 Kubernetes 就剛好採用了這一設計思路。
• 中心化設計的問題：
  1. 中心化的設計存在的最大問題是「領導」的安危問題，若是「領導」出了問題，則羣龍無首，整個集羣就奔潰了。但咱們難以同時安排兩個「領導」以免單點問題。
  2. 中心化設計還存在另一個潛在的問題，既「領導」的能力問題：能夠領導10我的高效工做並不意味着能夠領導100我的高效工做，因此若是系統設計和實現得很差，問題就會卡在「領導」身上。
• 領導安危問題的解決辦法： 大多數中心化系統都採用了主備兩個「領導」的設計方案，能夠是熱備或者冷備，也能夠是自動切換或者手動切換，並且愈來愈多的新系統都開始具有自動選舉切換「領導」的能力，以提高系統的可用性。

2)去中心化設計

• 衆生地位平等： 在去中心化的設計裏，一般沒有「領導」和「幹活的」這兩種角色的區分，你們的角色都是同樣的，地位是平等的，全球互聯網就是一個典型的去中心化的分佈式系統，聯網的任意節點設備宕機，都只會影響很小範圍的功能。
• 「去中心化」不是不要中心，而是由節點來自由選擇中心。 （集羣的成員會自發的舉行「會議」選舉新的「領導」主持工做。最典型的案例就是ZooKeeper及Go語言實現的Etcd）
• 去中心化設計的問題： 去中心化設計裏最難解決的一個問題是 「腦裂」問題 ，這種狀況的發聲機率很低，但影響很大。腦裂問題，這種狀況的發生機率很低，但影響很大。腦裂指一個集羣因爲網絡的故障，被分爲至少兩個彼此沒法通訊的單獨集羣，此時若是兩個集羣都各自工做，則可能會產生嚴重的數據衝突和錯誤。通常的設計思路是，當集羣判斷髮生了腦裂問題時，規模較小的集羣就「自殺」或者拒絕服務。

分佈式與集羣的區別是什麼？

• 分佈式： 一個業務分拆多個子業務，部署在不一樣的服務器上
• 集羣： 同一個業務，部署在多個服務器上。好比以前作電商網站搭的redis集羣以及solr集羣都是屬於將redis服務器提供的緩存服務以及solr服務器提供的搜索服務部署在多個服務器上以提升系統性能、併發量解決海量存儲問題。

CAP定理

在理論計算機科學中，CAP定理（CAP theorem），又被稱做布魯爾定理（Brewer's theorem），它指出對於一個分佈式計算系統來講，不可能同時知足如下三點：

• 一致性（Consistence） :全部節點訪問同一份最新的數據副本
• 可用性（Availability）:每次請求都能獲取到非錯的響應——可是不保證獲取的數據爲最新數據
• 分區容錯性（Partition tolerance） : 分佈式系統在遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性和可用性的服務。

CAP僅適用於原子讀寫的NOSQL場景中，並不適合數據庫系統。如今的分佈式系統具備更多特性好比擴展性、可用性等等，在進行系統設計和開發時，咱們不該該僅僅侷限在CAP問題上。

注意：不是所謂的3選2（不要被網上大多數文章誤導了）:

現實生活中，大部分人解釋這必定律時，經常簡單的表述爲：「一致性、可用性、分區容忍性三者你只能同時達到其中兩個，不可能同時達到」。實際上這是一個很是具備誤導性質的說法，並且在CAP理論誕生12年以後，CAP之父也在2012年重寫了以前的論文。

當發生網絡分區的時候，若是咱們要繼續服務，那麼強一致性和可用性只能2選1。也就是說當網絡分區以後P是前提，決定了P以後纔有C和A的選擇。也就是說分區容錯性（Partition tolerance）咱們是必需要實現的。

我在網上找了不少文章想看一下有沒有文章提到這個不是所謂的3選2，用百度半天沒找到了一篇，用谷歌搜索找到一篇比較不錯的，若是想深刻學習一下CAP就看這篇文章把，我這裏就很少BB了：《分佈式系統之CAP理論》 ： www.cnblogs.com/hxsyl/p/438…

BASE理論

BASE理論由eBay架構師Dan Pritchett提出，在2008年上被分表爲論文，而且eBay給出了他們在實踐中總結的基於BASE理論的一套新的分佈式事務解決方案。

BASE 是 Basically Available（基本可用） 、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性） 三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結，是基於CAP定理逐步演化而來的，它大大下降了咱們對系統的要求。

BASE理論的核心思想

即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。也就是犧牲數據的一致性來知足系統的高可用性，系統中一部分數據不可用或者不一致時，仍須要保持系統總體「主要可用」。

針對數據庫領域，BASE思想的主要實現是對業務數據進行拆分，讓不一樣的數據分佈在不一樣的機器上，以提高系統的可用性，當前主要有如下兩種作法：

• 按功能劃分數據庫
• 分片（如開源的Mycat、Amoeba等）。

因爲拆分後會涉及分佈式事務問題，因此eBay在該BASE論文中提到了如何用最終一致性的思路來實現高性能的分佈式事務。

BASE理論三要素

1. 基本可用

基本可用是指分佈式系統在出現不可預知故障的時候，容許損失部分可用性。可是，這毫不等價於系統不可用。

好比：

• 響應時間上的損失:正常狀況下，一個在線搜索引擎須要在0.5秒以內返回給用戶相應的查詢結果，但因爲出現故障，查詢結果的響應時間增長了1~2秒
• 系統功能上的損失：正常狀況下，在一個電子商務網站上進行購物的時候，消費者幾乎可以順利完成每一筆訂單，可是在一些節日大促購物高峯的時候，因爲消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面

2. 軟狀態

軟狀態指容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間進行數據同步的過程存在延時

3. 最終一致性

最終一致性強調的是系統中全部的數據副本，在通過一段時間的同步後，最終可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性。

總結

本文主要是簡單的介紹了三個常見的概念： 分佈式系統設計理念 、 CAP定理 、 BASE理論 ，關於分佈式系統的還有不少不少東西。

我是Snailclimb,一個以架構師爲5年以內目標的小小白。 歡迎關注個人微信公衆號:"Java面試通關手冊"（一個有溫度的微信公衆號，期待與你共同進步~~~堅持原創，分享美文，分享各類Java學習資源)

最後，就是使用阿里雲服務器一段時間後，感受阿里雲真的很不錯，就申請作了阿里雲大使，而後這是個人優惠券地址.