?高可擴展性系統的一些理論基礎

?

?

?

在2000年ACM的PODC座談會上加州大學伯克利教授 Eric Brewer在主題“建立可靠的分布式系統”的演講中提出了所謂的CAP定律，至今被大型網絡公司（如亞馬遜 ）作為系統構架基礎理論廣泛應用。

在討論CAP定律前，先介紹CAP定律涉及到三個關鍵概念：一致性（Consistency），可用性（Availability） 和分區容差（Partition Tolerance）。一致性的含義是指系統在執行操作后處于一致的狀態；一些寫操作后所有的讀操作都看到共享數據源上相同的更新結果。 可用性，尤其高可用性意味著系統的設計和實現避免了SPOF，在集群中的節點崩潰或部分軟硬件由于升級維護而不能工作的情況下系統可以繼續正常事務處理。 分區容差反應了系統在網絡物理分區發生改變（比如節點無法相互連接，或者動態的添加和刪除節點) 而繼續工作的能力。

布魯爾聲稱，一個“共享數據系統”至多可以同時實現CAP三個特征中兩個。 CAP定律本身并不復雜。 一個簡單的理解是：為了提高系統的可用性，防止SPOF，根本的策略是冗余復制，為了保證復制雙方不受相互影響，必須考慮復制雙方的分區； 分區必然需要考慮復制雙方的狀體同步， 也就是一致性問題。

進一步的討論需要引入新的概念BASE。

（一）ACID / BASE

ACID是數據庫管理系統（DBMS)中事務所具有的四個特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）、持久性（Durability）。例如銀行轉帳，從原賬戶扣除金額，以及向目標賬戶添加金額，這兩個數據庫操作的總和，構成一個完整的邏輯過程 。這個過程具有ACID屬性， 保證了整個系統中的總金額沒有變化， 系統一直處于一致性狀態。

維基，博客，社交網絡等互聯網每天產生海量數據需要處理，儲存和分析。系統

需要根據數據的不同性質， 在性能，可靠性，可用性，一致性和耐久性之間權衡。事實是，Facebook狀態更新， 微博論壇的留言并不嚴格需要ACID。只要業務層和表示層實現了處理不一致的數據的策略， 放寬ACID要求，可以避免系統在數據庫層上的瓶頸，對實現高效，高擴展的系統構架產生巨大的靈活性。

在另一方面， 即使對于大型電子商務網站和大型銀行系統，越來越多的系統架構使用大量的“廉價，低端和不十分穩定的”機器， 實現相對低成本的可用性和無限可擴展性， 但同時引入了分區容差（P)的因素。 CAP定理說明在一致性，可用性和分區容差中必須犧牲其中一種屬性。在分區容差不可避免 的大型和超大數據規模的Web應用系統中， 如何選擇呢？作者有一次和一家著名電子商務公司的構架師聊天， 他說即使公司內部的系統出現嚴重問題，用戶下單是不會受到影響的。 從商業角度來考慮，可用性比嚴格的一致性更有價值。

當然， 系統放寬ACID要求的同時， 必須有能力在業務層和表示層處理不一致的數據。 這就引入了BASE的概念。

BASE是Basic Available(基本上可用) Soft State(軟狀態) 和 Eventually consistent（最終一致性）的首字母縮寫詞。 因為ACID在英語中也有酸性的意思， BASE有堿性的意思，技巧的表明了截然兩種不同的性質。BASE系統強調系統的可用性，適度退化和性能 。通俗的講，應用程序基本上在所有的時間都是工作（基本上可用），雖然沒有在所有的時間狀態都是一致的（軟狀態）， 但最終將達到確定一致的狀態（最終的一致性）

Table 3.2.: ACID vs. BASE (cf. [Bre00, slide 13])

ACID	BASE
強的一致性 隔離 強調事務的“提交” 嵌套事務 可用性？ 保守的（封閉式） 演進困難（如 架構）	弱的一致性 – 過時的數據 OK 可用性第一 盡力而為 近似答案 OK 主動式（開放式） 簡單！ 更快 更容易演變

?

?

?

?

ACID是封閉的和嚴格要求每一個操作一致性（CAP中的C）；BASE是開放的，認為數據庫的一致性存在于變化不定的狀態流中。雖然這聽起來很玄妙，BASE在實際中非常易于管理，而且獲得了ACID無法獲得的高水平的可用性（CAP中的A）。

BASE的可用性在于，通過降低嚴格一致性要求而去偶聯分布式節點， 部分系統故障因而不影響系統的整體狀態； 同時松散化各個節點的關聯，架構上也進一步支持了高的橫向可擴展性。

上面所有的討論中， 一致性的觀點是關鍵。一致性的概念比較廣泛，數據一致性通常指關聯數據之間的邏輯關系是否正確和完整，我們主要討論數據復制情況下的一致性。 先舉個 一致性模型的例子，假設以下情況下發生：

• 行X復制到節點M和N

• 客戶端A到節點N對行X進行寫操作

• 經過的時間t的期間，客戶端B從節點M讀取行X

可以從兩方面來看待一致性問題: 從用戶/程序員的角度，確定客戶端B是否能夠讀到客戶端A的寫操作結果； 從服務器的角度，更新操作是如何完成的，系統所承諾的訪問結果是什么。

?

早期對分布式數據一致性的研究，強調數據分布對用戶的透明性。 用戶應該和使用單一系統一樣使用分布式系統，如果單一系統的特性沒法獲得，早期的選擇是讓整體系統失效。90年代中期， 隨著大規模網絡系統的出現，研究人員開始重新審視分布式系統的設計理念。Eric的 CAP 定律就是這種反思的總結。

?

常用的一致性模型有： 【見WIKI】

• 嚴格一致性（linearizability, strict/atomic Consistency） 要求無論寫操作發生在哪個副本上 ， 所有的讀操作必須返回最近完成的寫操作的結果 。 這意味著對于不同節點上的讀寫操作必須執行分布式事務協議（如兩階段提交協議）來保證嚴格的一致性。分布式事務協議的本質是把各個副本通過協議緊密偶聯，造成了SPOF而影響系統的可用性。 這和CAP定理得到的結論相同：ACID強調嚴格的一致性。

• 順序一致性（sequential consistency）：程序在各個機器上并行運行時，任何一種有效的交錯訪問順序都是可認可的行為，但所 有使用者以同樣的順序看到對同一數據的操作。 順序一致性是常見的多線程程序執行順序的模型。

• 因果一致性（causal consistency ，Hutto和Ahamad，1990 ）是順序一致性（SC)的弱化 。 因果一致性 按有無可能的潛在因果聯系來區分各事件。 假設進程P1寫變量x，然后P2讀出x，寫入y。這里讀出x和寫入y之間可能有潛在的因果聯系，因為y的計算很可能決定于P2讀到的x值（即P1寫入的值）。 只有存在因果關系的寫操作才要求所有使用者以相同的次序看到，對于無因果關系的寫入則并行進行，無次序保證 。但在實現時可以使用向量時間戳建立與維護因果依賴圖，需要一定開銷。

• 管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的進一步弱化，要求由某一個進程完成的寫操作可以被其他所有的進程按照順序的感知到，就像寫入一個的管道一樣；而從不同進程中來的寫操作則無需保證順序。管道一致性實現 相對來說比較容易。

• 弱一致性（weak consistency）：只要求對共享數據結構的訪問保證順序一致性。弱一致性的另一個定義是指所有弱于順序一致性的一致性模型。

• 釋放一致性（release consistency）： 使用兩個不同的操作語句acquire-release。需要寫入前acquire該對象，寫操作結束后release。 提供 釋放一致性也就意味著當release發生后和新的acquire前，所有使用者應該可以看到該操作結果。

• 最終一致性（eventual consistency）：當沒有新更新的情況下，系統隨著時間的推移最終將返回最后寫入的值；雖然在數據更新過程中，因為各個副本的同步需要時間，客戶端可能會面臨數據不一致的狀態。允許采用最終一致性模型的關鍵前提是：偶爾讀出陳舊數據是可以接受的。

• delta consistency：系統會在固定的delta時間窗口內達到一致。

• 最終一致性的幾種具體實現：
  1、讀不舊于寫一致性（Read-your-writes consistency， RYOW）：使用者讀

到的數據，總是不舊于自身上一個寫入的數據。RYOW一致性是一種特殊因果一致性。RYOW意味著一個用戶完成寫操作后可以立刻看到更新的結果，即使讀寫是發生在不同的服務器上。其他用戶對他的更新不是立刻可見的。
2、會話一致性（Session consistency）：也翻譯成任務一致性， 它比RYOW更弱化，是RYOW的應用版。使用者在一個會話中才保證讀寫一致性，啟動新會話后則一致性失效。
3、單讀一致性（Monotonic read consistency）：任何使用者讀到的數據總是不舊于任何使用者上一次讀到的數據。
4、單寫一致性（Monotonic write consistency）：保持同一個使用者寫操作的順序，寫操作完成后才能開始下一次的寫入。這是編程的最低要求。

在實踐應用中可以組合應用上述的幾種最終一致性模式。比如 單讀一致性 和 會話一致性的組合應用。 設計師需要根據應用程序實際需要來選擇特定模式。Werner Vogels認為：在很多互聯網應用中，單讀一致性和RYOW 可以提供足夠的一致性了。

最終一致性模式并不是高度分布式系統獨有的。比如傳統RDBMS的異步備份機制在備份恢復過程中就存在數據不一致的時間窗口。

?

下面轉入服務器端的一致性討論。

在分片構架上引入復制的概念不僅僅增加了系統的可靠性， 而且可以均衡對特定物理節點的讀操作的負載。 Voldermort開發小組 認為，以下3個因素影響在分片數據上的讀寫操作。

N: 讀寫操作對象的副本數目

R: 讀操作涉及到的副本數目

W: 寫操作中阻斷的副本數目， 也是寫操作完成前同步寫入的副本數目。

在RYOW一致性模型中， 以下關系成立

R +W > N

也就是當讀操作的副本和寫操作的副本有重疊時，系統可以保證比較嚴格的一致性。 在完全同步的條件下， R+W = R + N > N , 系統嚴格一致。

系統的常用使用方式和優化要求決定了設置R,W，N的值。如果系統把一致性放

在首位，如果設W=N，這樣同時增加了W失敗的可能性；常用的策略是設W=3， 然后再寫更新其他副本。這種情況往往導致 R+ W <= N， 系統具有弱化的最終一致性。 對于Amazon的Dynamo 而言，為了處理終端用戶的寫操作高可用性，R,W，N的值設為 N=3， R=2， W=2。

系統架構的其他因素也影響一致性的獲得。 服務器前端的負載平衡使用粘性連接（Sticky Connection), 將很容易獲得 會話一致性和 單讀一致性。有的時候 RYOW一致性也可以通過客戶端使用寫操作的版本號來實現。

?

EBay和Amazon都公開表示他們的系統嚴格不使用2PC。如何在沒有2PC的分布式系統中保證系統的一致性？ 上面引入的BASE概念表明， 最終一致性答案不再是一個BOOL值，而是一個范圍； 最終一致性的獲得，也不再是一個原子操作，而是一個過程。 常見的策略包括：精心設計的數據庫讀寫操作的順序； 通過異步事件或者協調批處理（reconciliation batch)來實現最終一致性。

轉載于:https://blog.51cto.com/6927843/1172097

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的创建可扩展性系统-4的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。