http://www.jianshu.com/p/fcc28b195fa9

• 如果多個邏輯控制流在時間上發生了重疊, 就會產生併發.
• 邏輯控制流是指一次程式操作.
  • 如讀取或者更新記憶體變數的值.
  • 更新的併發性: 多執行緒同時更新記憶體值而產生的併發.

• 目標:
  • 增加系統可用性, 防止因單點故障引起的系統不可用.
  • 提高系統的整體效能, 通過負載均衡, 讓分佈在不同地方的資料副本都能為使用者提供服務.
• 缺陷:
  • 為了解決複製延遲, 阻塞寫入動作直到所有的複製完成, 會嚴重影響寫入的效能.
  • 在不影響系統執行效能前提下,保證資料一致性是不可能的.
  • 一致性的級別:
    • 強一致性. 最好的使用者體驗, 但是會影響效能.
    • 弱一致性. 儘可能快地但不保證資料一致狀態.
      • 分為會話一致性和使用者一致性.
    • 最終一致性. 保證一定時間內,達到資料一致狀態.
      • 屬於弱一致性的特例. 是目前最被廣泛接收的.

• 常見問題
  • 通訊異常,節點故障.
  • 網路分割槽:
    • 部分節點的網路延遲過大, 導致只有部分節點間能夠正常通訊的現象.
  • 請求與響應的三態: 成功,失敗,超時.
• ACID.
  • Atomicity: 事務中的所有操作只能全部執行或者全部不執行.
  • Consistency: 事務的執行不能破壞資料庫中資料的完整性和一致性.
    • 當資料庫在一些事務尚未完成時發生故障, 會導致部分修改寫入, 而處於不一致狀態.
  • Isolation: 併發環境中,事物相互隔離.
    • Read Uncommitted.允許髒讀.
    • Read Committed. 允許不可重複讀(一次事物多次讀取相同值時, 原始讀取不可重複).
    • Repeatable Read(鎖定行). 事務過程中多次讀取同一資料,其值和開始時是一致的. 可能有幻影資料(鎖定行範圍).
    • Serializable. 所有事務序列執行,不支援併發.
  • Durability: 事務成功結束後,其對資料庫的更新要被永久儲存下來.
• 分散式事務
  • 由多個分散式的操作(子事務)序列組成, 巢狀型的事務. 需要兼顧可用性和一致性.
  • CAP. 最多隻能同時滿足其中的兩項. 分割槽容錯性是必須的,平衡的是Consistency和Availability.
    • Consistency. 資料在多個副本間的一致性.
    • Availability. 使用者的每個請求總能在有限的時間內返回結果.
    • Partition tolerance. 遇到任何網路分割槽(子網路)故障時,對外提供滿足一致性和可用性的服務.除非整個網路故障.
  • BASE 理論. 既然無法達到強一致性, 那麼採用適當的方式來達到最終一致性.
    • Basically Available. 出現不可預知的故障時, 允許損失部分可用性.
      • 造成響應時間上的損失, 功能上的損失.
    • Soft state. 允許系統中的資料存在中間狀態.
      • 即資料副本間的同步存在延遲.
    • Eventually Consistent. 它包含五種變種:
      • Causal consistency. 更新程序完成後通知程序B,程序B拿到的是更新後的資料.
      • Read your writes. 程序更新資料後,自己總是能讀取到更新過的新值.
      • Session consistency. 在同一會話中實現read your writes的一致性.
      • Monotonic read consistency. 程序讀取某資料項後,後續的資料訪問不能返回舊值.
      • Monotonic write consistency. 保證來自同一程序的寫操作順序地執行.
    • 核心: 犧牲強一致性來獲得可用性.

• 跨越多個分散式節點的事務操作,需引入協調器(Coordinator)來排程,節點稱為參與者(Participant).
  • Coordinator 排程Participan t的行為, 並最終決定是否要把事務真正進行提交.
• 兩階段提交協議(2PC, Two-Phase Commit).
  • 關係型資料庫的通用做法, 屬於強一致性演算法.
  • 階段: 提交事務請求(投票); 執行事務提交(執行).
    • 採用先嚐試後提交的方式.
  • 缺點:
    1. 同步阻塞(participant 會一直等待它人的響應);
    2. 單點問題(coordinator);
    3. 資料不一致性(階段二如果有節點沒有收到提交訊息時);
    4. 太過保守(coordinate 只能依靠超時來處理長時間無響應的participant).
• 三階段提交協議(3PC)
  • 階段:
    • CanCommit, PreCommit, Do Commit.
    • participant 在PreCommit 階段執行事務操作,並將Undo 和Redo 資訊記錄到事務log 中.
  • 缺點:
    • 進入Do commit階段,參與者在等待(協調者的提交/中斷指令)超時後,會繼續進行事務提交. 可能導致資料的不一致性.
  • 優勢:
    • 降低了參與者的阻塞範圍, 且在單點故障後繼續達成一致性.