事務及分佈式事務概念介紹

轉載請註明出處 http://www.paraller.com
原文排版地址 點擊獲取更好閱讀體驗算法

事務及分佈式事務

ACID

  • 原子性 (Atomicity) :事務是數據庫的邏輯工做單位,事務中包括的諸操做要麼全作,要麼全不作。
  • 一致性 (Consistency):事務執行的結果必須是使數據庫從一個一致性狀態變到另外一個一致性狀態。一致性與原子性是密切相關的。
  • 隔離性 (Isolation):一個事務的執行不能被其餘事務干擾。
  • 持續性/永久性 (Durability):一個事務一旦提交,它對數據庫中數據的改變就應該是永久性的。

應用場景:在分佈式系統中,每一個節點雖然能夠知曉本身的操做時成功或者失敗,卻沒法知道其餘節點的操做的成功或失敗。
當一個事務跨越多個節點時,爲了保持事務的 ACID 特性,須要引入一個做爲協調者的組件來統一掌控全部節點(稱做參與者)的操做結果並最終指示這些節點是否要把操做結果進行真正的提交(好比將更新後的數據寫入磁盤等)。數據庫

主要流程

第一階段 | Vote
  • 協調者會問全部的參與者結點,是否能夠執行提交操做。
  • 各個參與者開始事務執行的準備工做:如:爲資源上鎖,預留資源,寫 undo/redo log……
  • 參與者響應協調者,若是事務的準備工做成功,則迴應「能夠提交」,不然迴應「拒絕提交」。
第二階段 | Decision
  • 若是全部的參與者都回應「能夠提交」,那麼,協調者向全部的參與者發送「正式提交」的命令。參與者完成正式提交,並釋放全部資源,而後迴應「完成」,協調者收集各結點的「完成」迴應後結束這個 Global Transaction。
  • 若是有一個參與者迴應「拒絕提交」,那麼,協調者向全部的參與者發送「回滾操做」,並釋放全部資源,而後迴應「回滾完成」,協調者收集各結點的「回滾」迴應後,取消這個 Global Transaction。
出現的問題

一、同步阻塞操做,必然會很是大地影響性能。網絡

二、另外是超時問題,好比,框架

  • 若是第一階段中,參與者沒有收到詢問請求,或是參與者的迴應沒有到達協調者。那麼,須要協調者作超時處理,一旦超時,能夠看成失敗,也能夠重試。
  • 若是第二階段中,正式提交發出後,若是有的參與者沒有收到,或是參與者提交/回滾後的確認信息沒有返回,一旦參與者的迴應超時,要麼重試,要麼把那個參與者標記爲問題結點剔除整個集羣,這樣能夠保證服務結點都是數據一致性的。
  • 糟糕的狀況是,第二階段中,若是參與者收不到協調者的 commit/fallback 指令,參與者將處於「狀態未知」階段,參與者徹底不知道要怎麼辦,好比:若是全部的參與者完成第一階段的回覆後(可能所有 yes,可能所有 no,分佈式

    可能部分 yes 部分 no),若是協調者在這個時候掛掉了。那麼全部的結點徹底不知道怎麼辦(問別的參與者都不行)。爲了一致性,要麼死等協調者,要麼重發第一階段的 yes/no 命令。
改進: 三階段提交
  • 把二階段提交的第一個段 break 成了兩段:詢問,而後再鎖資源和最後真正提交。
  • 三段提交的核心理念是:在詢問的時候並不鎖定資源,除非全部人都贊成了,纔開始鎖資源。

(事務及分佈式事務)[http://blog.daocloud.io/micro...]性能

CAP 定理和數據一致性

CAP 定理

CAP 定理:一個分佈式系統最多隻能同時知足一致性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)這三項中的兩項。網站

一致性

一致性指更新操做成功後,全部節點在同一時間的數據徹底一致。常見的一致性類別:搜索引擎

  • Weak(弱一致性):當你寫入一個新值後,讀操做在數據副本上可能讀出來,也可能讀不出來。好比:某些 cache 系統。
  • Eventually(最終一致性):當你寫入一個新值後,有可能讀不出來,但在某個時間窗口以後保證最終能讀出來。好比:DNS,電子郵件、Amazon S3,Google 搜索引擎這樣的系統。
  • Strong(強一致性):新的數據一旦寫入,在任意副本任意時刻都能讀到新值。好比:文件系統,RDBMS,Azure Table 都是強一致性的。

Paxos

  • Paxos 算法是基於消息傳遞且具備高度容錯特性的一致性算法,是目前公認的解決分佈式一致性問題最有效的算法之一。
  • 常見的分佈式系統中,總會發生諸如機器宕機或網絡異常(包括消息的延遲、丟失、重複、亂序,還有網絡分區)等狀況。設計

    Paxos 算法須要解決的問題就是如何在一個可能發生上述異常的分佈式系統中,快速且正確地在集羣內部對某個數據的值達成一致,而且保證不論發生以上任何異常,都不會破壞整個系統的一致性。

Raft

Raft是斯坦福的 Diego Ongaro、John Ousterhout 兩我的以易懂(Understandability)爲目標設計的一致性算法,在 2013 年發佈了論文:In Search of an Understandable Consensus Algorithm
從 2013 年發佈到如今不過只有兩年,到如今已經有了十多種語言的 Raft 算法實現框架code

參考網站

CAP 定理和數據一致性

相關文章
相關標籤/搜索