banner
reverie

reverie

CRDT - 無衝突複製資料型別

CRDT 是 "Conflict-free Replicated Data Types" 的縮寫,中文可以翻譯為 "無衝突複製資料類型"。這是一種可以在多個設備或節點間複製和同步的資料結構,而不需要進行複雜的衝突解決。CRDTs 被設計用來解決分佈式系統中的一些困難問題,特別是在可能出現網絡分區或延遲的情況下。

先來想像一下一個常見的問題:多人在線協作編輯同一份文件(比如 Google Docs)。每個人都可以在自己的設備上進行編輯,然後這些更改需要同步到其他所有人的設備上。但是,如果兩個人幾乎同時在同一個位置進行了編輯,我們應該怎麼處理呢?這就是一個典型的衝突問題。

傳統的解決方式可能是使用某種鎖機制或者衝突解決策略,但是這些方法往往會使系統變得複雜,且在網絡延遲或斷開的情況下表現不佳。

CRDTs 提供了一種更優雅的解決方案。CRDTs 的設計思路是,如果我們能設計出一種資料結構,使得對其的所有可能操作都是可交換的(也就是說,不管操作的順序如何,結果都是一樣的),那麼我們就可以避免衝突。這樣,每個設備都可以自由地、無需等待或鎖定地進行操作,然後將這些操作同步到其他設備。只要所有的操作最終都能到達所有的設備,那麼所有設備上的資料狀態就會一致。

CRDTs 是一種資料結構,用於簡化分佈式資料存儲系統和多用戶應用。在許多系統中,某些資料的副本需要存儲在多台計算機(即副本)上。這類系統的例子包括:

  • 存儲資料在本地設備上並需要將該資料同步到同一用戶的其他設備上的移動應用(例如日曆,筆記,聯繫人或提醒);
  • 分佈式數據庫,這些數據庫在同一數據中心或不同位置維護數據的多個副本,以便在一些副本離線時系統能夠繼續正常工作;
  • 在線協同軟件,如 Google Docs, Trello, Figma 等,多個用戶可以同時對同一文件或資料進行更改;
  • 大規模資料存儲和處理系統,這些系統複製資料以實現全球範圍內的可擴展性。

所有這些系統都需要處理資料可能在不同副本上同時被修改的情況。大體上,處理此類資料修改的方式有兩種:

  • 強一致性複製
    副本彼此協調以決定何時以及如何應用修改。這種方法支持如可串行化事務和線性化等強一致性模型。然而,等待這種協調會降低這些系統的性能;此外,CAP 定理告訴我們,當一個副本從系統的其餘部分斷開時(例如由於網絡分區,或者因為它是一個具有間歇性連接性的移動設備),無法對該副本進行任何資料更改。
  • 樂觀複製
    用戶可以獨立於其他副本修改任何副本上的資料,即使該副本處於離線或與其他副本斷開連接狀態。這種方法實現了最大的性能和可用性,但當多個客戶端或用戶同時修改同一份資料時可能會導致衝突。然後需要在副本之間通信時解決這些衝突。

CRDTs 用於樂觀複製系統中,負責解決衝突。 CRDTs 確保無論在不同副本上進行了什麼資料修改,資料始終可以合併為一致的狀態。這個合併由 CRDT 自動執行,不需要任何特殊的衝突解決程式碼或用戶干預。

此外,CRDTs 的一個重要特性是支持去中心化運作:它們並不假定使用單一伺服器,因此可以在對等網絡和其他去中心化環境中使用。在這方面,CRDTs 與 Google Docs、Trello 和 Figma 使用的演算法不同,這些工具要求用戶之間的所有通訊都通過伺服器進行。

為了實現這一點,CRDT 需要對資料的修改進行一些特殊的處理。比如,對於一個 CRDT 集合,添加和刪除操作可能需要記住一些額外的資訊,以便在其他設備進行同步時可以正確地處理衝突。其中一個常見的類型,即 “Grow-only Set(只增不減集合)”。在這個類型的 CRDT 中,你可以添加元素到集合中,但不能從集合中移除元素。這個設計的好處是,添加操作是可交換的,即不論你按照何種順序添加元素,最後的結果都是相同的。

但是,現實生活中我們常常需要從集合中移除元素。為了解決這個問題,另一種 CRDT,叫做 “Two-phase Set(兩階段集合)”。在這個類型的 CRDT 中,每一個元素都有兩個狀態:添加和刪除。初始狀態為添加,當你刪除一個元素時,其狀態轉為刪除。這樣,即使有其他設備同時添加同一元素,只要有一個設備標記了該元素為刪除,該元素就會被視為已刪除。這也就是說,刪除操作在這個集合中具有優先級。這樣的設計使得在不同設備之間同步時能夠正確地處理衝突。

總的來說,CRDTs 的設計都是以這樣的方式來處理資料修改的,即通過一些特殊的處理,使得操作可以在不同的設備上並行進行,並且可以在合併時保持資料的一致性。這樣的設計使得 CRDTs 非常適合於分佈式系統和多用戶應用,因為它們可以處理並行操作和網絡延遲帶來的複雜問題。

CRDT 有兩種類型,都可以提供強最終一致性:基於操作的 CRDT 和基於狀態的 CRDT。

基於狀態的 CRDT 通常更容易設計和實現;它們對通訊底層的唯一要求是某種 gossip protocol。它們的缺點是,每個 CRDT 的整個狀態最終都必須傳輸給其他每個副本,這可能開銷很大。相比之下,基於操作的 CRDT 只傳輸更新操作,通常很小。然而,基於操作的 CRDT 需要通訊中介軟體的保證;在傳輸給其他副本時,操作不會被丟棄或重複,而且它們是按因果順序傳輸的。

  • CmRDT
    基於操作的 CRDT 也被稱為交換性複製資料類型(commutative replicated data types)。CmRDT 副本只通過傳輸更新操作來傳播狀態。例如,單一整數的 CmRDT 可以廣播操作(+10)或(-20)。副本接收更新並在本地應用這些更新。這些操作是可交換的。然而,它們不一定幂等。因此,通訊基礎設施必須確保一個副本上的所有操作都被傳遞給其他副本,沒有重複,但以任何順序傳輸都是可以的。

  • CvRDT
    基於狀態的 CRDT 被稱為收斂複製資料類型(convergent replicated data types)。與 CmRDT 相反,CvRDT 將其完整的本地狀態發送給其他副本,在這些副本中,狀態必須通過可交換的、可結合的並且是幂等的函數合併。合併函數為任何一對副本的狀態提供連接,因此所有狀態的集合形成一個半格。更新函數必須按照與半格相同的偏序規則,單調地增加內部狀態。函數必須內部狀態,根據與半網格相同的偏序規則。

載入中......
此文章數據所有權由區塊鏈加密技術和智能合約保障僅歸創作者所有。