Open kylemocode opened 2 years ago
線性一致性(一種流行的一致性模型):其目標是使多副本資料看起來好像只有一個副本一樣,並使其上所有操作都原子性地生效。
因果性,因果性對系統中的事件施加了順序(什麼發生在什麼之前,基於因與果)。
為何需要共識?
共識:所有節點一致同意所做決定,且這一決定不可撤銷
如果你只有一個節點,或者你願意將決策的權能分配給單個節點,所有這些事都很簡單。
但變更領導者的共識演算法仍然必須 -> 使用「容錯的共識演算法與容錯的共識系統」
大多數複製的資料庫至少提供了 最終一致性,但這提供了比較弱的保證 → 更強一致性模型,線性一致性
順序一致性(Sequential Consistency)中 process 只關心大家認同的順序一樣就行,不需要與全局時鐘一致,線性(Linearizability consistency)就更嚴格,從這種偏序(partial order)要達到全序(total order)
要求是:
1.任何一次讀都能讀到某個數據的最近一次寫的數據。 2.系統中的所有 process,看到的操作順序,都與全局時鐘下的順序一致。
如果只有一個節點,或者願意將決策的權能分配給單個節點,所有這些事都很簡單。能夠提供線性一致的操作,唯一性約束,完全有序的複製日誌,以及更多。 —→若需要解決共識的問題,可以找類似 ZooKeeper 的工具解決
一致性與共識
構建容錯系統的最好方法,是找到一些帶有實用保證的通用抽象,實現一次,然後讓應用依賴這些保證。 i.e.: 事務
複製延遲問題 收斂為弱保證:不能及時解決複製延遲問題
新鮮度保證:系統保障讀取到的值為最新的值 寄存器 應用: 鎖定和領導選舉 約束和唯一性保證 跨信道的時序依賴 (i.e.圖片上傳與發送) 複製方法與線性一致性 單主複製 — 可能線性一致 共識算法 — 線性一致 多主複製 — 非線性一致 無主複製 — 取決於法定人數配置與異步網路延遲 代價 i.e. 網路中斷的可能性造成單主複製無法寫入 CAP定理:分布式系統不可能同時滿足以下三點 一致性 可用性 分區容錯性
因果順序不是全序 — 不能比較兩者之間的因果順序 完全線性一致性系統中沒有併發 線性一致性強於因果一致性,但因果一致性較線性一致性能保證更好的性能 全序廣播 可靠交付:消息不會被丟失 全序交付:消息以相同的順序傳遞給節點 i.e. 設定追加日誌
節點能達成共識仰賴:領導選舉、原子提交 兩階段提交:跨多節點的事物提交 — 仰賴協調者 XA事務:使用XA API查詢操作是否為分布式事務的一部份 懷疑時持有鎖
一致同意 — 沒有兩個節點的決定為不同 完整性 — 沒有節點可以決定兩次 終止 — 尤為崩潰的節點決定最終值
事務隔離主要是為了 避免由於同時執行事務而導致的競爭狀態,而分散式一致性主要關於 在面對延遲和故障時如何協調副本間的狀態。
當應用準備提交時,協調者開始階段 1 :它傳送一個 準備(prepare) 請求到每個節點,詢問它們是否能夠提交。
一致性保證
收斂(convergence) 因為我們預計所有的副本最終會收斂到相同的值,這是一個非常弱的保證 —— 它並沒有說什麼時候副本會收斂
線性一致性 基本的想法是讓一個系統看起來好像只有一個數據副本,而且所有的操作都是原子性的。有了這個保證,即使實際中可能有多個副本,應用也不需要擔心它們。
NOTE:
顺序一致性中进程只关心大家认同的顺序一样就行,不需要与全局时钟一致,线性就更严格,从这种偏序(partial order)要达到全序(total order)
約束和唯一性保證
使用者名稱或電子郵件地址必須唯一標識一個使用者
蘭伯特時間戳 (計數器,節點 ID)$(counter, node ID)$。兩個節點有時可能具有相同的計數器值,但透過在時間戳中包含節點 ID,每個時間戳都是唯一的。