分佈式BASE理論:數據一致性模型!

你知道的越多,不知道的就越多,業餘的像一棵小草!

你來,我們一起精進!你不來,我和你的競爭對手一起精進!

編輯:業餘草

來源:http://tinyurl.com/y8btadm3

推薦:https://www.xttblog.com/?p=5035

前言

詳解 CAP 定理 Consistency(一致性)、 Availability(可用性)、Partition toleranc中,提到了CAP中只能三者擇其二,有CP(一致性+分區容錯性)和AP(可用性+分區容錯性)兩種選擇。

一般來說,放棄強一致性,追求分區容錯性和可用性,是很多分佈式系統設計的選擇。在工程實踐中,基於CAP定義逐步演化出了Base理論。本文主要對以下兩個問題進行介紹:

Base理論有哪些內容?

Base理論下的一致性模型又有哪些?(若文章有不正之處,或難以理解的地方,請多多諒解,歡迎指正)

Base理論

Base理論是三要素的縮寫:基本可用(Basically Available)、軟狀態(Soft-state)、最終一致性(Eventually Consistency)。

可能這三個要素比較抽象,舉個栗子吧。

基本可用

相對於CAP理論中可用性的要求:【任何時候,讀寫都是成功的】,“基本可用”要求系統能夠基本運行,一直提供服務,強調的是分佈式系統在出現不可預知故障的時候,允許損失部分可用性。

相比於正常的系統,可能是響應時間延長,或者是服務被降級。

舉個栗子,在秒殺活動中,如果搶購人數太多,超過了系統的QPS峯值,可能會排隊或者提示限流。

軟狀態

相對於ACID事務中原子性要求【要麼做,要麼不做】,強調的是強制一致性,要求多個節點的數據副本是一致的,強調數據的一致性。這種原子性可以理解爲”硬狀態“。

而軟狀態則允許系統中的數據存在中間狀態,並認爲該狀態不影響系統的整體可用性,即允許系統在不同節點的數據副本上存在數據延時。

舉個栗子,CSDN個人主頁的粉絲數,如果有用戶關注了某個博主,該博主的粉絲數需要過一段時間纔會顯示正確的數據。

最終一致性,數據不可能一直處於軟狀態,必須在一個時間期限後達到各個節點的一致性。在期限過後,應當保證所有副本中的數據保持一致性,也就是達到了數據的最終一致性。

在系統設計中,最終一致性實現的時間取決於網絡延時、系統負載、不同的存儲選型,不同數據複製方案設計等因素。也就是說,誰都不保證用戶什麼時候能看到更新好的數據,但是總會看到的。

最終一致性要求的多個節點數據副本保持一致性,也是說,在不同機器上是物理時鐘保持一致,這就是全局時鐘。沒有全局時鐘,絕對的內部一致性是沒有意義的。不同機器上的物理時鐘難以同步,導致無法區分在分佈式系統中多個節點的事件時序。

既然如此,那麼我們只需要所有機器有相同的時間就行了,如果兩個節點之間不需要交互,它們的時間甚至都不需要同步。所以我們只要抓住一個重點:達成一致的是節點之間交互的事件發生順序,而非時間。

所以有很多數據一致性的不同模型。

數據一致性模型

強一致性:當更新操作完成後,任何多個後續進行訪問時都會返回最新的值,就是用戶剛提交就能看到更新了的數據,這對用戶是最友好的。但根據CAP理論,這勢必也要犧牲可用性。

弱一致性:系統在寫入數據成功後,不承諾立即能讀到最新的值,也不承諾什麼時候能讀到,但是過一段時間之後用戶可以看到更新後的值。那麼用戶讀不到最新數據的這段時間被稱爲“不一致窗口時間”。

根據《分佈式CAP理論:爲什麼CAP理論中的三個指標不能同時滿足呢?》並結合 ZooKeeper 框架得知,它採用的是 CAP 理論中的 CP 架構,即追求強一致性和分區容錯性。

但其實這並不嚴謹,因爲 ZooKeeper 在寫入值之後,會交給 Leader 處理,Zab 協議只需保證半數從節點成功即可,那麼這就會有節點數據是老的數據,如此,有可能客戶端讀出的數據不是最新的數據。而且,因爲節點通過 zxid 順序地接受 Leader 的廣播,所以 ZooKeeper 不能保證所有的信息能被馬上看到,不過最終都會看到噠。

讀到這裏,有的讀者們可能會想:小編,你是不是在玩我?

且慢!凡事都有但是。想實現 ZooKeeper 讀寫的強一致性也是可以的。在 ZooKeeper 中有一個 sync() 命令,只要我們每次讀的時候調用 sync() 強制同步數據,就可以保證讀出的數據都是最新的。

呼,所以 ZooKeeper 雖然默認實現數據的弱一致性,但是也可以通過調整代碼,實現數據的強一致性。所以將 ZooKeeper 作爲 CP 架構的例子也是可以滴~

最終一致性作爲弱一致性中的特例,強調的是所有數據副本,在經過一段時間的同步後,最終能夠到達一致的狀態,不需要實時保證系統數據的強一致性。而到達最終一致性的時間,其實就是上文提到的不一致窗口時間。

根據業務需求的不同,最終一致性中又有很多種情況:

  • 因果一致性:要求有因果關係的操作順序得到保證,非因果關係的操作順序則無所謂。例如微信朋友圈的評論以及對評論的答覆所構成的因果關係,有興趣可以瞭解一下。

    • 會話一致性:在操作順序得到保證的前提下,保證用戶在同一個會話裏讀取數據時保證數據是最新的,如分佈式系統Session一致性解決方案。

  • 單調讀一致性:用戶讀取某個數據值後,其後續操作不會讀取到該數據更早版本的值。

  • 單調寫一致性:要求數據的所有副本,以相同的順序執行所有的更新操作,也稱爲時間軸一致性。

當然,這裏只是簡單列出來了一些比較常見的一致性模型,按不完全統計,應該是有15種一致性模型的,有興趣的朋友可以瞭解一下。

結語

本文主要是對基於CAP理論的BASE理論進行了介紹,從BASE理論中的最終一致性展開了對不同數據一致性模型的介紹。以下參考資料對於理解這塊有較大的幫助,有些可能看不懂,那就收藏起來,等什麼時候翻一翻說不一定就看懂了呢~

如果本文對你的學習有幫助,請給一個贊吧,這會是我最大的動力~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章