分布式系統
所謂分布式系統顧名思義就是利用多臺計算機協同解決單臺計算機所不能解決的計算、存儲等問題。單機系統與分布式系統的最大的區別在于問題的規模，即計算、存儲的數據量的區別。
1.為什么使用分布式系統
1.單臺服務器性能優先，綜合利用多個節點的處理能力，提高整體的服務能力。單個業務量比較大單機無法支撐時，拆分到多個節點上各自處理一部分。
2.多個模塊拆分解耦，各自解決不同的業務問題，每個可以由不同的團隊負責，交互周期變短。
2.如何拆分成分布式
將一個單機問題使用分布式解決，首先要解決的就是如何將問題拆解為可以使用多機分布式解決，使得分布式系統中的每臺機器負責原問題的一個子集。由于無論是計算還是存儲，其問題輸入對象都是數據，所以如何拆解分布式系統的輸入數據成為分布式系統的基本問題。
拆分的最高目標：可無限擴展、各個節點負載比較均衡、復雜度低、元數據維護比較簡單
哈希方式
哈希分布數據的缺點同樣明顯，突出表現為可擴展性不高，一旦集群規模需要擴展，則幾乎所有的數據需要被遷移并重新分布。工程中，擴展哈希分布數據的系統時，往往使得集群規模成倍擴展，按照數據重新計算哈希，這樣原本一臺機器上的數據只需遷移一半到另一臺對應的機器上即可完成擴展。
針對哈希方式擴展性差的問題，一種思路是不再簡單的將哈希值與機器做除法取模映射，而是將對應關系作為元數據由專門的元數據服務器管理.同時，哈希值取模個數往往大于機器個數，這樣同一臺機器上需要負責多個哈希取模的余數。但需要以較復雜的機制維護大量的元數據。哈希分布數據的另一個缺點是，一旦某數據特征值的數據嚴重不均，容易出現“數據傾斜”（data skew）問題。
哈希分布數據的另一個缺點是，一旦某數據特征值的數據嚴重不均，容易出現“數據傾斜”（data skew）問題
按數據范圍分布
按數據范圍分布是另一個常見的數據分布式，將數據按特征值的值域范圍劃分為不同的區間，使得集群中每臺（組）服務器處理不同區間的數據。
工程中，為了數據遷移等負載均衡操作的方便，往往利用動態劃分區間的技術，使得每個區間中服務的數據量盡量的一樣多。當某個區間的數據量較大時，通過將區間“分裂”的方式拆分為兩個區間，使得每個數據區間中的數據量都盡量維持在一個較為固定的閾值之下。
一般的，往往需要使用專門的服務器在內存中維護數據分布信息，稱這種數據的分布信息為一種元信息。甚至對于大規模的集群，由于元信息的規模非常龐大，單臺 計算機無法獨立維護，需要使用多臺機器作為元信息服務器。
按數據量分布
數據量分布數據與具體的數據特征無關，而是將數據視為一個順序增長的文件，并將這個文件按照某一較為固定的大小劃分為若干數據塊（chunk），不同的數據塊分布到不同的服務器上。與按數據范圍分布數據的方式類似的是，按數據量分布數據也需要記錄數據塊的具體分布情況，并將該分布信息作為元數據使用元數據服務器管理。
由于與具體的數據內容無關，按數據量分布數據的方式一般沒有數據傾斜的問題，數據總是被均勻切分并分布到集群中。當集群需要重新負載均衡時，只需通過遷移數據塊即可完成。集群擴容也沒有太大的限制，只需將部分數據庫遷移到新加入的機器上即可以完成擴容。按數據量劃分數據的缺點是需要管理較為復雜的元信息，與按范圍分布數據的方式類似，當集群規模較大時，元信息的數據量也變得很大，高效的管理元信息成為新的課題。
一致性哈希
https://www.cnblogs.com/lpfuture/p/5796398.html
一致性哈希（consistent hashing）是另一個種在工程中使用較為廣泛的數據分布方式。一致性哈希最初在P2P 網絡中作為分布式哈希表（DHT）的常用數據分布算法。一致性哈希的基本方式是使用一個哈希函數計算數據或數據特征的哈希值，令該哈希函數的輸出值域為一個封閉的環，即哈希函數輸出的最大值是最小值的前序。將節點隨機分布到這個環上，每個節點負責處理從自己開始順時針至下一個節點的全部哈希值域上的數據。
使用一致性哈希的方式需要將節點在一致性哈希環上的位置作為元信息加以管理，這點比直接使用哈希分布數據的方式要復雜。然而，節點的位置信息只于集群中的機器規模相關，其元信息的量通常比按數據范圍分布數據和按數據量分布數據的元信息量要小很多。
為此一種常見的改進算法是引入虛節點（virtual node）的概念，系統初始時就創建許多虛節點，虛節點的個數一般遠大于未來集群中機器的個數，將虛節點均勻分布到一致性哈希值域環上，其功能與基本一致性哈希算法中的節點相同。為每個節點分配若干虛節點。操作數據時，首先通過數據的哈希值在環上找到對應的虛節點，進而查找元數據找到對應的真實節點。使用虛節點改進有多個優點。首先，一旦某個節點不可用，該節點將使得多個虛節點不可用，從而使得多個相鄰的真實節點負載失效節點的壓里。同理，一旦加入一個新節點，可以分配多個虛節點，從而使得新節點可以 負載多個原有節點的壓力，從全局看，較容易實現擴容時的負載均衡。
3.可用性
3.1無法避免的設備故障和網絡異常
1、通信異常：從集中式向分布式演變的過程中，必然引入網絡因素，由于網絡本身的不可靠性，因此 也引入了額外的問題。分布式系統需要在各個節點之間進行網絡通信，因此每次網絡通信都會伴隨著網絡不可用的風險，網絡光纖、路由器或是DNS等硬件設備或 是系統不可用都會導致最終分布式系統無法順利完成一次網絡通信。另外，即使分布式系統各個節點之間的網絡通信能夠正常進行，其延時也會大于單機操作。通常 我們認為現代計算機體系結構中，單機內存訪問的延時在納秒數量級（通常是10ns），而正常的一次網絡通信的延遲在0.1~1ms左右（相當于內存訪問延 時的105倍），如此巨大的延時差別，也會影響到消息的收發過程，因此消息丟失和消息延遲變得非常普遍
2、網絡分區：當網絡由于發生異常情況，導致分布式系統中部分節點之間的網絡延時不斷增大，最終導致組成分布式系統的所有節點中，只有部分節點之間能夠正常通信，而另一些節點則不能----我們將這個現象稱為網絡分區。當網絡分區出現時，分布式系統會出現局部小集群，在極端情況下，這些局部小集群會獨立完成原本需要整個分布式系統才能完成的功能，包括對數據的事物處理，這就對分布式一致性提出了非常大的挑戰
3、三態：上面兩點，我們已經了解到在分布式環境下，網絡可能會出現各式各樣的問題，因此分布式系統的每一次請求與響應，存在特有的三態概念，即成功、失敗、超時。 在傳統的單機系統中，應用程序在調用一個函數之后，能夠得到一個非常明確的響應：成功或失敗。而在分布式系統中，由于網絡是不可靠的，雖然在絕大部分情況 下，網絡通信也能夠接受到成功或失敗的響應，當時當網絡出現異常的情況下，就可能會出現超時現象，通常有以下兩種情況：
（1）由于網絡原因，該請求并沒有被成功地發送到接收方，而是在發送過程中就發生了消息丟失現象
（2）該請求成功地被接收方接收后，進行了處理，但是在將響應反饋給發送方的過程中，發生了消息丟失現象
當出現這樣的超時現象時，網絡通信的發起方是無法確定當前請求是否被成功處理的
4、節點故障：節點故障則是分布式環境下另一個比較常見的問題，指的是組成分布式系統的服務器節點出現的宕機或"僵死"現象，通常根據經驗來說，每個節點都有可能出現故障，并且每天都在發生
5、存儲數據丟失:對于有狀態節點來說，數據丟失意味著狀態丟失，通常只能從其他節點讀取、恢復存儲的狀態。
6、異常處理原則：被大量工程實踐所檢驗過的異常處理黃金原則是：任何在設計階段考慮到的異常情況一定會在系統實際運行中發生，但在系統實際運行遇到的異常卻很有可能在設計時未能考慮，所以，除非需求指標允許，在系統設計時不能放過任何異常情況。
3.2副本
因為物理故障是無法避免的，所以需要做數據冗余，提高可用性。
副本（replica/copy）指在分布式系統中為數據或服務提供的冗余。對于數據副本指在不同的節點上持久化同一份數據，當出現某一個節點的存儲的數據丟失時，可以從副本上讀到數據。數據副本是分布式系統解決數據丟失異常的唯一手段。另一類副本是服務副本，指數個節點提供某種相同的服務，這種服務一般并不依賴于節點的本地存儲，其所需數據一般來自其他節點。
副本協議是貫穿整個分布式系統的理論核心。
副本的理想狀況：副本也可提供服務；一個副本故障或者多個副本故障，都不影響服務；不會帶來數據一致性問題；同時系統復雜度不會很高；副本不怎么占用資源。
主從和時效性是副本要考慮的兩個重要問題。
主從主要由單主，多主，無主三種方式。
時效性主要有同步、異步、版同步三種方式。
4.CAP定理
一個經典的分布式系統理論。CAP理論告訴我們：一個分布式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分區容錯性（P：Partition tolerance）這三個基本需求，最多只能同時滿足其中兩項。
1、一致性
在分布式環境下，一致性是指數據在多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作后，應該保證系統的數據仍然處于一直的狀態。
對于一個將數據副本分布在不同分布式節點上的系統來說，如果對第一個節點的數據進 行了更新操作并且更新成功后，卻沒有使得第二個節點上的數據得到相應的更新，于是在對第二個節點的數據進行讀取操作時，獲取的依然是老數據（或稱為臟數 據），這就是典型的分布式數據不一致的情況。在分布式系統中，如果能夠做到針對一個數據項的更新操作執行成功后，所有的用戶都可以讀取到其最新的值，那么 這樣的系統就被認為具有強一致性
2、可用性
可用性是指系統提供的服務必須一直處于可用的狀態，對于用戶的每一個操作請求總是能夠在有限的時間內返回結果。這里的重點是"有限時間內"和"返回結果"。
"有限時間內"是指，對于用戶的一個操作請求，系統必須能夠在指定的時間內返回對 應的處理結果，如果超過了這個時間范圍，那么系統就被認為是不可用的。另外，"有限的時間內"是指系統設計之初就設計好的運行指標，通常不同系統之間有很 大的不同，無論如何，對于用戶請求，系統必須存在一個合理的響應時間，否則用戶便會對系統感到失望。
"返回結果"是可用性的另一個非常重要的指標，它要求系統在完成對用戶請求的處理后，返回一個正常的響應結果。正常的響應結果通常能夠明確地反映出隊請求的處理結果，即成功或失敗，而不是一個讓用戶感到困惑的返回結果。
3、分區容錯性
分區容錯性約束了一個分布式系統具有如下特性：分布式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環境都發生了故障。
網絡分區是指在分布式系統中，不同的節點分布在不同的子網絡（機房或異地網絡） 中，由于一些特殊的原因導致這些子網絡出現網絡不連通的狀況，但各個子網絡的內部網絡是正常的，從而導致整個系統的網絡環境被切分成了若干個孤立的區域。 需要注意的是，組成一個分布式系統的每個節點的加入與退出都可以看作是一個特殊的網絡分區。
既然一個分布式系統無法同時滿足一致性、可用性、分區容錯性三個特點，所以我們就需要拋棄一樣：
用一張表格說明一下：
需要明確的一點是，對于一個分布式系統而言，分區容錯性是一個最基本的要求。因為 既然是一個分布式系統，那么分布式系統中的組件必然需要被部署到不同的節點，否則也就無所謂分布式系統了，因此必然出現子網絡。而對于分布式系統而言，網 絡問題又是一個必定會出現的異常情況，因此分區容錯性也就成為了一個分布式系統必然需要面對和解決的問題。因此系統架構師往往需要把精力花在如何根據業務 特點在C（一致性）和A（可用性）之間尋求平衡。
5.BASE理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源于對大規模互聯網系統分布式實踐的總結， 是基于CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。接下來看一下BASE中的三要素：
1、基本可用
基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性----注意，這絕不等價于系統不可用。比如：
（1）響應時間上的損失。正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由于出現故障，查詢結果的響應時間增加了1~2秒
（2）系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面
2、軟狀態
軟狀態指允許系統中的數據存在中間狀態，并認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時
3、最終一致性
最終一致性強調的是所有的數據副本，在經過一段時間的同步之后，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
總的來說，BASE理論面向的是大型高可用可擴展的分布式系統，和傳統的事物ACID特性是相反的，它完全不同于ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許數據在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分布式場景中，不同業務單元和組件對數據一致性的要求是不同的，因此在具體的分布式系統架構設計過程中，ACID特性和BASE理論往往又會結合在一起。
5.衡量分布式系統的指標
性能：系統的吞吐能力，指系統在某一時間可以處理的數據總量，通常可以用系統每秒處理的總的數據量來衡量；系統的響應延遲，指系統完成某一功能需要使用的時間；系統的并發能力，指系統可以同時完成某一功能的能力，通常也用QPS(query per second)來衡量。上述三個性能指標往往會相互制約，追求高吞吐的系統，往往很難做到低延遲；系統平均響應時間較長時，也很難提高QPS。
可用性：系統的可用性(availability)指系統在面對各種異常時可以正確提供服務的能力。系統的可用性可以用系統停服務的時間與正常服務的時間的比例來衡量，也可以用某功能的失敗次數與成功次數的比例來衡量。可用性是分布式的重要指標，衡量了系統的魯棒性，是系統容錯能力的體現。
可擴展性：系統的可擴展性(scalability)指分布式系統通過擴展集群機器規模提高系統性能（吞吐、延遲、并發）、存儲容量、計算能力的特性。好的分布式系統總在追求“線性擴展性”，也就是使得系統的某一指標可以隨著集群中的機器數量線性增長。
一致性：分布式系統為了提高可用性，總是不可避免的使用副本的機制，從而引發副本一致性的問題。越是強的一致的性模型，對于用戶使用來說使用起來越簡單。
6.分布一致性的提出
在分布式系統中要解決的一個重要問題就是數據的復制。在我們的日常開發經驗中，相 信很多開發人員都遇到過這樣的問題：假設客戶端C1將系統中的一個值K由V1更新為V2，但客戶端C2無法立即讀取到K的最新值，需要在一段時間之后才能 讀取到。這很正常，因為數據庫復制之間存在延時。
分布式系統對于數據的復制需求一般都來自于以下兩個原因：
1、為了增加系統的可用性，以防止單點故障引起的系統不可用
2、提高系統的整體性能，通過負載均衡技術，能夠讓分布在不同地方的數據副本都能夠為用戶提供服務
數據復制在可用性和性能方面給分布式系統帶來的巨大好處是不言而喻的，然而數據復制所帶來的一致性挑戰，也是每一個系統研發人員不得不面對的。
所謂分布一致性問題，是指在分布式環境中引入數據復制機制之后，不同數據節點之間 可能出現的，并無法依靠計算機應用程序自身解決的數據不一致的情況。簡單講，數據一致性就是指在對一個副本數據進行更新的時候，必須確保也能夠更新其他的 副本，否則不同副本之間的數據將不一致。
那么如何解決這個問題？一種思路是"既然是由于延時動作引起的問題，那我可以將寫入的動作阻塞，直到數據復制完成后，才完成寫入動作"。 沒錯，這似乎能解決問題，而且有一些系統的架構也確實直接使用了這個思路。但這個思路在解決一致性問題的同時，又帶來了新的問題：寫入的性能。如果你的應 用場景有非常多的寫請求，那么使用這個思路之后，后續的寫請求都將會阻塞在前一個請求的寫操作上，導致系統整體性能急劇下降。
總得來說，我們無法找到一種能夠滿足分布式系統所有系統屬性的分布式一致性解決方案。因此，如何既保證數據的一致性，同時又不影響系統運行的性能，是每一個分布式系統都需要重點考慮和權衡的。于是，一致性級別由此誕生：
1、強一致性
這種一致性級別是最符合用戶直覺的，它要求系統寫入什么，讀出來的也會是什么，用戶體驗好，但實現起來往往對系統的性能影響大
2、弱一致性
這種一致性級別約束了系統在寫入成功后，不承諾立即可以讀到寫入的值，也不久承諾多久之后數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）后，數據能夠達到一致狀態
3、最終一致性
最終一致性是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個數據一致的狀態。這里之所以將最終一致性單獨提出來，是因為它是弱一致性中非常推崇的一種一致性模型，也是業界在大型分布式系統的數據一致性上比較推崇的模型
