歷史文章推薦：
分散式系統設計理念
分散式系統架構的第一原則是不要分佈！這句話看似矛盾實則揭露了分散式系統的很多特徵。
分散式系統的目標與要素
分散式系統的目標是提升系統的整體效能和吞吐量另外還要儘量保證分散式系統的容錯性（假如增加10臺伺服器才達到單機執行效果2倍左右的效能，那麼這個分散式系統就根本沒有存在的意義）。
即使採用了分散式系統，我們也要盡力運用併發程式設計、高效能網路框架等等手段提升單機上的程式效能。
分散式系統設計兩大思路：中心化和去中心化
1）中心化設計：
- 兩個角色： 中心化的設計思想很簡單，分散式叢集中的節點機器按照角色分工，大體上分為兩種角色： “領導” 和 “幹活的”
- 角色職責： “領導”通常負責分發任務並監督“幹活的”，發現誰太閒了，就想發設法地給其安排新任務，確保沒有一個“幹活的”能夠偷懶，如果“領導”發現某個“幹活的”因為勞累過度而病倒了，則是不會考慮先嚐試“醫治”他的，而是一腳踢出去，然後把他的任務分給其他人。其中微服務架構 Kubernetes 就恰好採用了這一設計思路。
- 中心化設計的問題：
- 中心化的設計存在的最大問題是“領導”的安危問題，如果“領導”出了問題，則群龍無首，整個叢集就奔潰了。但我們難以同時安排兩個“領導”以避免單點問題。
- 中心化設計還存在另外一個潛在的問題，既“領導”的能力問題：可以領導10個人高效工作並不意味著可以領導100個人高效工作，所以如果系統設計和實現得不好，問題就會卡在“領導”身上。
- 領導安危問題的解決辦法： 大多數中心化系統都採用了主備兩個“領導”的設計方案，可以是熱備或者冷備，也可以是自動切換或者手動切換，而且越來越多的新系統都開始具備自動選舉切換“領導”的能力，以提升系統的可用性。
2)去中心化設計
- 眾生地位平等： 在去中心化的設計裡，通常沒有“領導”和“幹活的”這兩種角色的區分，大家的角色都是一樣的，地位是平等的，全球網際網路就是一個典型的去中心化的分散式系統，聯網的任意節點裝置當機，都只會影響很小範圍的功能。
- “去中心化”不是不要中心，而是由節點來自由選擇中心。 （叢集的成員會自發的舉行“會議”選舉新的“領導”主持工作。最典型的案例就是ZooKeeper及Go語言實現的Etcd）
- 去中心化設計的問題： 去中心化設計裡最難解決的一個問題是 “腦裂”問題 ，這種情況的發聲概率很低，但影響很大。腦裂問題，這種情況的發生概率很低，但影響很大。腦裂指一個叢集由於網路的故障，被分為至少兩個彼此無法通訊的單獨叢集，此時如果兩個叢集都各自工作，則可能會產生嚴重的資料衝突和錯誤。一般的設計思路是，當叢集判斷髮生了腦裂問題時，規模較小的叢集就“自殺”或者拒絕服務。
分散式與叢集的區別是什麼？
- 分散式： 一個業務分拆多個子業務，部署在不同的伺服器上
- 叢集： 同一個業務，部署在多個伺服器上。比如之前做電商網站搭的redis叢集以及solr叢集都是屬於將redis伺服器提供的快取服務以及solr伺服器提供的搜尋服務部署在多個伺服器上以提高系統效能、併發量解決海量儲存問題。
CAP定理
- 一致性（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學習資源)
最後，就是使用阿里雲伺服器一段時間後，感覺阿里雲真的很不錯，就申請做了阿里雲大使，然後這是我的優惠券地址.