移動計算雲分散式資料快取服務,實現快速可靠的跨區域多活複製

語言: CN / TW / HK
摘要:本文介紹了一種在移動計算雲中擴充套件分散式資料快取服務以實現跨區域多活複製的方案。

本文分享自華為雲社群《移動計算雲分散式資料快取服務,實現快速可靠的跨區域多活複製》,作者: 敏捷的小智。

本文翻譯自華為加拿大研所論文,英文原文連結:https://www.sciencedirect.com/science/article/pii/S1877050921014101

第18屆國際移動系統和普適計算大會(MobiSPC)
2021年8月9日至12日,比利時魯汶

移動計算雲分散式資料快取服務,實現快速可靠的跨區域多活複製

Daniel House, Heng Kuang*, Kajaruban Surendran, Paul Chen

加拿大安大略省萬錦市 華為加拿大研究院

摘要

本文介紹了一種在移動計算雲中擴充套件分散式資料快取服務以實現跨區域多活複製的方案。闡述如何保證網路腦裂恢復後區域間資料的一致性,提出了一種跨區域副本資料同步的方法,能夠克服在嚴重網路腦裂下,快取資料操作的複製無法保證因果關係順序的情況。本文使用的是最流行的移動計算雲分散式資料快取服務——Redis記憶體資料庫,所述方案以外掛的形式進行應用(最大程度減少對快取服務端和客戶端的影響)。Redis開放了強大的擴充套件API,允許新的抽象資料型別與key關聯,但Redis並未對增加和管理全域性字典元資料提供直接支援,這在本方案得以實現。本方案使用該擴充套件API來增加CRDT(無衝突複製資料型別),解決來自多個區域的寫入衝突。

© 2021 The Authors. Published by Elsevier B.V.

This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)

Peer-review under responsibility of the Conference Program Chairs.

關鍵詞:雲資料快取;跨區域多活;無衝突複製資料型別CRDT;可用性

1. 引言

移動計算雲應用要求即便在高峰時段也要保證最短響應時間。因此,使用分散式資料快取服務來增強效能就顯得尤為重要。實際上,資料快取已幾乎成為一項必備移動計算雲服務,其中,AWS ElastiCache 快取服務、Azure Redis 快取服務、阿里云云資料庫 Redis 版、華為分散式快取服務(DCS),都使用Redis作為快取引擎。

* Heng Kuang. Tel.:

E-mail address:

移動計算雲中,分散式資料快取服務依賴跨區域多活來保證全球各地的終端使用者都能夠使用到可靠、高效能的移動雲應用。隨著移動計算雲中的應用數量不斷增加,如今的應用需要快速響應來自各大洲的資料讀寫請求,響應時間可能需要比跨洋簡訊送達的時間還快。不管網路和元件出現什麼問題,應用必須始終保持可用,始終追求快速解決一致性問題,幾乎要衝破CAP定理 [10] 的束縛。這種需求場景可能出現在世界不同地區的使用者需要編輯共享資料(如多人文件協同)時,需要同時點選網頁、訂機票時,或者某個使用者需要在不同裝置間保持資料統一時。還有一些場景,使用者雖然感知不到資料共享或複製本身,但卻能感知時延和可靠性,比如購物車應用。

單向快取複製中,所有寫請求都發送到快取的中心例項,這個中心例項是所有副本的主節點。當主節點發生故障時,其餘副本中的一個被選舉為新的主節點。一旦網路腦裂發生,與主節點位於同一分割槽中的客戶端和副本不受影響,能夠繼續執行,但其他分割槽中的客戶端和副本只有兩種選擇:被阻塞,或是在其所在分割槽中選舉新的主節點。如果是購物類應用,阻塞會直接影響銷量,因此絕不允許阻塞發生。如果每個分割槽都選舉出自己的主節點,則該分割槽中所有的主節點需要同步資料,形成單主節點的格局。但在多活複製中,沒有主節點,資料統一持續進行,腦裂後恢復也並不需要額外處理。當世界各地的使用者對應用資料同時進行操作(比如訂機票時),如果只有單主節點處理寫入請求,對於距離該節點很遠的使用者來說時延太大,體驗很差。此時,就可以使用多活複製,實現全體使用者的時延差不多。

要想設計出好的多活複製系統,就需要轉變思維,因為衝突解決的結果可能並不直觀。設計人員可以選擇發現衝突、上報衝突然後人工解決,也可以選擇自動解決衝突。即便在單向複製中依照last-writer-wins,給key賦一個簡單的值,對設計人員來說也可能有新穎獨特的選項,例如可以採取一鍵多值[5],如果多個請求需要同時對一個值進行更改或刪除,可以選擇哪個請求中的操作獲勝。採用 [7] 中所實現的多活佇列,就能對同一條資料進行多次出隊。開發人員必須知曉這些選項,充分理解這種新思維,才能寫出有效的程式碼。新思維利用得當,單向複製中處理併發的思路就能夠簡化。必須要保持機動靈活的思維。

與單向複製相比,多活複製需要儲存和傳輸用於檢測和解決資料衝突的元資料,所以快取大小和複製期間的資料傳送量都會增加。保證最終一致性的演算法比單向複製中簡單的last-writer-wins規則複雜得多,實現過程更容易出錯,複製也更慢。跨區域多活要求在不同區域間快速可靠地雙向同步資料,原因如下:

• 即便跨地域的網路速度慢或不穩定,複製速度也必須能趕上不同區域的併發寫入速度。

• 必須保證所有區域資料的最終一致性。

• 資料寫入衝突的識別和解決都必須快速完成且保證一致性。現有的衝突解決機制中,Consensus / Quorum機制的吞吐量低,Multi-Version Concurrency Control機制的系統開銷大,last-writer-wins機制會造成應用間的不一致性。

• 使用元資料來解決資料變更所導致的衝突,不應影響資料在快取例項之間的可遷移性。

• 不管是對快取客戶端還是服務端,解決以上問題的同時,效能、應用以及快取服務的實現不能受到顯著影響。

為了在實現跨區域多活的同時滿足以上這些嚴苛的要求,越來越多的人開始關注到無衝突複製資料型別(下稱CRDT)。CRDT又分為基於操作的Commutative Replicated Data Types(CmRDT),和基於狀態的Convergent Replicated Data Type(CvRDT)。Redis是一種基於key與資料結構對映的開源記憶體資料庫,可以提供跨任意距離的單向複製,是業內最受歡迎的應用於移動計算雲的分散式資料快取服務之一。本文以Redis為例,提供了一種可用於在移動計算雲中構建跨區域分散式應用的關鍵架構。它結合CRDT和Module API(Redis用於擴充套件的外掛機制),在儘可能減少對Redis實現及其客戶端進行變更的基礎上,利用Redis實現雙向複製。

下文將介紹我們是如何在移動計算雲中通過擴充套件Redis快取服務來支援跨區域多活複製。內容將聚焦如何使用Redis及其擴充套件機制Redis Module,利用CRDT保證網路腦裂恢復後跨區域資料的一致性。後文結構如下:第2章節介紹CRDT在學界的理論研究和在業界的應用;第3章節概要介紹了我們提供的複製與衝突解決方案;第4章節探討如何使用CRDT實現最終一致性;第5章節比較了本方案與業界其他方案;第6章節對本文中的方法和經驗進行總結,並指出今後的工作方向。

2. 背景及相關工作

據我們所知,目前尚無移動計算雲廠商提供基於CRDT跨區域多活複製的資料快取服務。Redis公司的Redis Enterprise產品是唯一可以通過基於操作的Commutative Replicated Data Types(CmRDT)來支援該功能的記憶體資料庫軟體 [12],但也沒有官方文件描述Redis Enterprise是如何、由哪個元件(proxy、syncer還是Redis Module)來處理CRDT中的資料刪除部分。Roshi [13] 提供時間序列事件儲存,通過LWW元素集CRDT實現,使用有限的inline garbage collection。Roshi是基於Redis的分散式無狀態層,在互不通訊的叢集上覆制資料。Roshi專案已超過5年未更新。

AntidoteDB [15] 是一個跨區域複製的key-value資料庫,操作執行使用CRDT,免於同步。其跨區域複製基於ZeroMQ,支援的資料型別包括Register、Flag、Map、Set、Counter。Riak KV [16] 是一個分散式key-value資料庫,它使用基於狀態的Convergent Replicated Data Type(CvRDT),支援的資料型別包括Register、Flag、Map、Set、Counter、HyperLogLog。Riak KV不跟蹤物理時鐘,而是跟蹤邏輯時鐘(dotted version vectors),以識別和解決區域之間的衝突。Azure Cosmos DB是一種NoSQL資料庫,其資料庫引擎的核心型別系統天生支援CRDT [17],但也沒有公開文件描述它支援哪些資料型別,以及是如何支援這些資料型別的。相反,Cosmos DB的文件解釋了什麼是last-writer-wins衝突解決策略和自定義衝突解決策略,以及如何配置這兩種策略。Cosmos DB使用反熵通道將試探性寫入從一個資源分割槽複製到同一個分割槽組中的其他資源分割槽。

多活複製和CRDT演算法有著豐富悠久的歷史,可以追溯到1975年 [8],比邏輯時鐘還要早 [1]。目前,已經出現了許多種類的CRDT。它們的主要共同點在於,資料的遠端副本可以同時更新,衝突解決可以使用本地資料,所有副本資料最終都會保持一致。要實現有效的快取複製,就必須有豐富的CRDT支援。本文討論的資料型別僅限於單值register和map。其他有用的CRDT還有多值register、counter、list和set。

register是一個物件,我們可以為其分配不透明資料,並從中讀取資料。[9] 提到了多值register,本文僅討論單值register。首個CRDT演算法 [8] 使用物理時間戳來實現值是單值register的map。[8] 提供的演算法能夠滿足標準增刪改查操作,同時確保了強最終一致性。

單值register是基於狀態的CRDT,這種CRDT非常可靠,只要訊息最終能夠送達,即便訊息無序或多次投遞也沒關係。register通常通過version vector來實現。當兩個version vector無法比較,就使用物理時間戳;當物理時間戳相同時,就使用更新register的節點ID。

不同CRDT需要不同的全域性資料。 -state CRDT需要因果關係的上下文,Replicated Hash Tables (RHTs)[2] 要求每個key都有一個向量時鐘來解決衝突和識別垃圾資料,Replicated Growable Array(RGA)[2] 則需要訊息佇列和last-vector-clock-processed,以確保訊息投遞符合因果關係順序並識別垃圾資料。 -CRDT map非常可靠。與Roh [2]和Wuu [3] 提到的map不同, -CRDT map不依賴於向量時鐘或基於因果關係的投遞,也不受訊息重排和多次投遞的影響。在本文中,我們使用一種 -CRDT演算法來處理單值register。

3. 系統架構

我們針對移動計算雲中分散式資料快取服務的跨區域多活複製方案由四個邏輯元件組成:資料快取服務Redis的CRDT模組、Replicator、Replayer、以及Replicator和Replayer的操作日誌,如圖1和2所示。Replicator和Replayer的實現機制相同,但作為兩種模式執行。

圖1 系統構成

圖2 CRDT模組

CRDT模組負責:

• 從快取服務客戶端或Replayer(從其他區域複製)接收快取操作。

• 對於讀操作,從快取服務資料庫獲取值,並將其返回給快取服務客戶端。

• 對於寫操作,生成解決潛在值衝突所需的元資料。

• 儲存寫操作生成的元資料。

• 通過元資料確定寫操作是否與快取服務資料庫中的對應資料衝突。

• 如果不存在衝突,並且其version vector是最新的,則將值寫入快取服務資料庫,然後將其複製到Replicator。

• 如果存在衝突,則根據CRDT衝突解決規則將值寫入資料庫。

Replicator負責:

• 作為其所在區域中快取服務端的副本,通過沿用資料快取服務中的主從複製機制,接收CRDT模組複製過來的成功的寫操作。

• 為這些操作生成ID,作為額外的元資料,並將這些操作推送到其複製管道。

• 將操作記錄在自己的操作日誌中。

• 當達到觸發條件(例如,每隔1秒或當複製佇列的大小達到1KB),將複製佇列中的操作傳送給其他區域的Replayer。

• 如果區域之間存在網路腦裂,則通過比較Replayer記錄的操作ID,識別操作日誌中傳送失敗的操作,重試傳送這些操作。

Replayer負責:

• 作為其他區域Replicator的副本,通過沿用資料快取服務中的主從複製機制,接收Replicator複製過來的寫操作。

• 將操作記錄在自己的操作日誌中。

• 作為快取服務客戶端,將操作回放到對應的快取服務端。

• 如果Replayer與其快取服務端之間存在網路腦裂,則利用操作ID和操作日誌查詢並重試尚未到達快取服務端的操作。

Replicator的操作日誌負責記錄同區域CRDT模組複製過來的成功的寫操作,然後在區域間網路腦裂恢復後,恢復這些操作。Replayer的操作日誌負責記錄其他區域Replicator複製過來的寫操作,然後在它與快取服務端間的網路腦裂恢復後,恢復這些操作。

4. 實現最終一致性

CRDT模組作為一種可動態加/解除安裝的共享庫載入到快取服務端,並可以直接開始攔截來自快取服務客戶端的請求,以對內部資料庫執行本地操作。CRDT模組更新資料庫,然後向其他區域傳送請求,對那些區域的資料庫進行遠端操作。圖2中的Replicator和Replayer相互協調,確保在沒有重大故障的情況下,所有遠端操作都能準確按順序投遞一次,但無法保證基於因果關係的投遞。當發生重大故障時,內部資料庫的全量資料將在區域之間交換。

4.1. 系統模型

通過Replicator和Replayer的協作,我們可以得到一種抽象系統模型,其中有n個節點(節點間不共享任何記憶體),。每個節點都有一個key-value儲存和一個控制儲存。每對節點(和),都有一個單向通訊管道,延遲很大([10] 中的報告顯示,洲際延遲可能高達0.25秒。)通訊管道可能處於活躍狀態或中斷狀態。處於活躍狀態時,訊息能夠按順序可靠地傳遞,不會重複。當管道中斷,其間傳送的訊息永遠不會送達。每當管道從中斷轉變到活躍時,節點就會使用該管道,將其資料庫的全量副本傳遞到,之後管道將恢復傳送遠端操作。本地客戶端生成查詢(使用本地資料庫進行應答,沒有副作用,不會觸發節點之間的任何通訊,因此本文不會進一步討論),並請求將本地操作加入本地資料庫內容中。

每個節點都有一個物理時鐘,用於生成物理時間戳。時鐘之間不進行同步。我們假設,在時刻,觀察到了包含個事件的有限序列Ei = {ei0, … einit},且當j < k,則eij發生在eik之前。對於,我們假設對於從Ni傳送到Nk的每一個訊息M,在Ei中都有一個傳送事件,在中都有一個接收事件,那麼發生在之前,寫入順序為。假設副本1(R1)的日誌L1包含操作o1,副本2(R2)的日誌L2包含操作o2。當o1  L2o2  L1時可以確定o1o2是併發的,表示為o1  o2,如果在任一日誌中o1出現在o2之前,則o1發生在o2之前,表示為o1 < o2

我們首先重新定義與字串的key相關聯的資料,因為它是CRDT單值register。Redis協議允許客戶端將key設定為任何二進位制BLOB。基於物件的強最終一致性 [6] 可以在register刪除或列表移除後回收空間。刪除key時,我們需要SWOR Map(Set-Wins, Observed-Remove)語義。由於Redis協議僅允許存在單值字串,因此我們使用單值register。RGA中key的SWOR Map語義可以理解為:當RGA上所有條目都已刪除並且最後一個tombstone已被GC程序回收,該key將被隱式刪除。如果在此之前刪除該key,可能會導致併發的list-add-right操作出現問題。RGA中的本地key刪除操作可以簡單擴充套件為一組列表移除操作。一個map可以在不同的時間包含不同的key。我們的目標是讓key表示CRDT值。隨著map的演進,key可以被刪除,可能很久之後key再重新創建出來。你可以為CRDT值設定一個基礎值或重置值,這種方法簡單、可用,但其弊端在於key必須持續存在才能表示基礎值。

4.2. 簡單的CRDT register

基於向量時鐘的register依賴全域性向量時鐘。每當register建立時,都會獲得新的向量時鐘。如果register每次都以“基礎”向量時鐘重新開始,則可能導致錯誤的值獲勝。基於dots的register依賴全域性因果關係。如果併發集足夠少(與節點數量相比),空間佔用就能比基於向量時鐘的方法更少。

每個副本都有自己的嚴格有序的事件歷史。為保障最終一致性,整個事件歷史都將隨每一條訊息一起傳送。接收訊息時,副本必須合併兩份事件歷史,才能獲得一份新的嚴格有序的事件歷史。要確保一致性,這種合併操作必須具備可結合及可交換性。獲得全序後,register的值來自最後一次操作。我們用⊥來表示無值,這個值是當歷史為空且全序中最後一個操作為時register的值。我們可以定義不同的合併操作來獲得不同的語義,如last-writer-wins或set-wins。傳送整個事件歷史的代價很大,因此需要想辦法減少傳送的資料量。

5. 其他方案的比較

本節我們將評估和對比其他聲稱能夠在記憶體資料庫雲服務或軟體中實現跨區域多活複製的方案。

5.1. 阿里雲ApsaraDB for Redis

阿里雲的ApsaraDB for Redis不支援CRDT,而是要求使用者的應用程式在使用跨區域多活複製功能時自行保障資料一致性 [11]。因此,使用者的應用程式在實現時必須保證以下幾點:

• 避免從不同區域同時寫入相同key(這很難控制)。

• 對Redis資料庫進行分割槽,使不同區域的使用者的應用程式只能寫入分配給該區域的可寫分割槽,同時從其他區域複製只讀分割槽(這將影響使用者的應用程式使用此功能的透明性,並使應用程式的實現更加複雜)。

如果無法做到以上幾點,相關區域中的資料就將變得不一致。例如,當一個key的value變更在兩個區域間同步後,可能導致兩個區域間的key value互換 [11];如果兩個區域中,一個key變更為不同的資料型別,也可能導致同步失敗 [11]。

5.2. KeyDB

KeyDB是Redis的分支,已經成為Redis的一個直接替代方案,支援多活副本和其他高階功能。當啟用多活複製時,KeyDB允許兩個主節點之間的迴圈連線,因此它還可以沿用Redis的主從複製機制。KeyDB使用last-writer-wins來解決主節點之間的衝突 [18]。每個寫操作都有時間戳,最新的寫操作獲勝。

但是,僅使用時間戳並不是一種可靠的衝突解決方案,因為可能會導致資料丟失,並且對許多資料型別(例如用於全球統計點贊數或關注數的計數器)還不夠用。“最後寫入”並不能得到保障,因為即使不同區域的服務端系統時鐘可以在一定的間隔內與全域性原子時鐘同步,但時間還是會漂移,每個服務端還是根據自己的系統時鐘來判斷寫操作的順序。此外,將系統時鐘回撥將導致意外的衝突解決。

5.3. Redis Enterprise

Redis Enterprise是開源Redis之上的增強版,提供了許多企業級功能,跨區域多活複製就是最重要的功能之一。Redis Enterprise中的CRDB(無衝突複製資料庫)是跨區域的多個Redis叢集的資料庫。每個叢集中的資料庫都是一個CRDB例項,使用Syncer將Redis操作複製到其他CRDB例項。Syncer沒有沿用Redis的複製機制,而是使用一種新的複製機制(從遠端主節點請求複製)。一個Redis Enterprise叢集包含Redis Shard(分片)、Proxy(代理)、Cluster Manager(叢集管理器)和REST API。

Redis Enterprise使用基於操作的CRDT,需要通過Syncer和Proxy複製額外的“effect”資料到所有CRDB例項。這些“effect”資料由使用Redis模組資料型別API [12] 構建的CRDT模組生成。但是,Redis Enterprise沒有明確說明“effect”資料中究竟包含什麼資訊,由誰(Syncer、Proxy還是Redis Module)以及如何將其應用於衝突解決。每個CRDB例項為每個資料庫條目和子條目維護一個向量時鐘,才能識別和解決區域之間的資料衝突 [12]。

5.4. 我們的方案

我們對單值register map實現了跨區域多活複製,使用向量時鐘來識別併發的資料更改,並對非併發更改進行正確排序。

Redis Enterprise是唯一可以使用基於操作的CRDT來支援跨區域多活複製的記憶體資料庫軟體,與之相比,我們的方案具有以下優勢:

• 結合基於狀態的CRDT和Redis模組資料型別API,避免將“effect”資料與資料庫條目分開儲存和複製,從而使這些條目的遷移更安全、更方便。

• 無需等待外部元件(Syncer或Proxy),能夠在CRDT模組中直接解決資料衝突,使衝突解決速度更快。

• 不需要代理(減少一次跳轉),從而對快取服務端和跨區域複製的效能影響降至最低。

• 沿用Redis資料快取服務的主從複製機制,可最大限度地提高區域內和跨區域複製的效能。

為證明本方案(基於華為DCS)的優勢,我們做了一個實驗,並在效能和CPU利用率維度與Redis Enterprise進行了比較,見以下步驟和圖3。

1. 在3臺主機上啟動3個華為DCS叢集(每個叢集中有3個Redis server,每個Redis server都載入CRDT模組),模擬3個區域中的3個多活Redis叢集。

2. 在每臺主機上啟動一組Replicator和Replayer(將它們連線到該主機上的3個Redis server)。

3. 執行3個memtier-benchmark,分別向這3個叢集傳送具有相同key範圍的寫請求,模擬對多活叢集的併發寫操作。使用工具斷開/重連不同主機上的Replicator與Replayer,模擬不同區域之間的網路腦裂。

4. 收集實驗資料,再對Redis Enterprise進行相同的實驗。以下是觀察結果:

1) 本方案即使在網路腦裂情況下,也實現了3個多活叢集之間的最終一致性。

2) 本方案比Redis Enterprise效能更好(寫/讀請求比為1:0時,效能是Redis Enterprise的200%),CPU利用率更低(寫/讀請求比為0:1時是Redis Enterprise的20%)。

圖3 與Redis Enterprise的效能和CPU利用率對比

6. 結論和今後方向

通過擴充套件快取服務的實現,我們學到了一些重要的經驗教訓。首先,在任何實際的CRDT應用中,如果CRDT例項能被刪除,都必須同時設計頂層map和map中的CRDT物件。map和物件必須共享某些資訊。比如,我們的單值register就需要訪問map中的因果關係。我們還發現,實現CRDT演算法需要仔細對比實際的訊息傳送環境與制定CRDT演算法時做出的理論假設。由於兩個區域之間的通訊管道時而中斷,我們的CRDT演算法需要能夠在區域之間執行全量同步,因此完全基於操作的CRDT演算法就不合適。

本次概念驗證將CRDT map與單值register相結合,用於移動計算雲中的分散式資料快取服務。我們希望進一步延展本次概念驗證,將Younes [4] 的可重置計數器和Almeida [5] 的集合也包含進來。如果要將Roh [2] 的RGA與CRDT map相結合,需要符合因果順序的訊息投遞。我們還希望通過基於因果關係的廣播協議 [6] 探索如何能實現資料快取服務中可行的RGA故障模式。

衝突解決要求每個key最終在每個節點中的型別相同。資料型別的單向優先順序雖然可以工作,但它只能是無規則的,而且我們到目前為止調研的型別晉級模式只能做到覆蓋與一個key關聯的所有先前的資料。完整的型別晉級網格可能並不存在,但仍然有可能存在一種型別衝突解決方案,既直觀,又能在衝突解決過程中保留儘可能多的資料。

參考文獻

[1] Leslie Lamport. 1978. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM. 21, 7 (July 1978), 558-565. DOI: https://doi.org/10.1145/359545.359563

[2] Hyun-Gul Roh, Myeongjae Jeon, Jin-Soo Kim, and Joonwon Lee. 2011. Replicated abstract data types: Building blocks for collaborative applications. Journal of Parallel and Distributed Computing. 71, 3 (March 2011), 354-368. DOI: https://doi.org/10.1016/j.jpdc.2010.12.006

[3] Gene T.J. Wuu and Arthur J. Bernstein. 1984. Efficient Solutions to the Replicated Log and Dictionary Problems. In Proceedings of the third annual ACM symposium on Principles of distributed computing (PODC’84). ACM Press, New York, NY, USA, 233-242. DOI: https://doi.org/10.1145/800222.806750

[4] Georges Younes, Paulo Sérgio Almeida, and Carlos Baquero. 2017. Compact Resettable Counters through Causal Stability. In Proceedings of the 3rd International Workshop on Principles and Practice of Consistency for Distributed Data (PaPoC’17). ACM Press, New York, NY, USA, 1-3. DOI: https://doi.org/10.1145/3064889.3064892

[5] Paulo Sergio Almeida, Ali Shoker, and Carlos Baquero. 2018. Delta State Replicated Data Types. Journal of Parallel and Distributed Computing. 111 (January 2018), 162-173. DOI: https://doi.org/10.1016/j.jpdc.2017.08.003

[6] Kenneth Birman, Andre Schiper, and Pat Stephenson. 1991. Lightweight causal and atomic group multicast. ACM Transactions on Computer Systems. 9, 3 (August 1991), 272-314. DOI: https://doi.org/10.1145/128738.128742

[7] Redis Labs. 2020. Developing with Lists in an Active-Active Database. Redis Labs. Retrieved November 1, 2020 from: https://docs.redislabs.com/latest/rs/references/developing-for-active-active/developing-lists-active-active/

[8] Paul R. Johnson and Robert H. Thomas. 1976. The maintenance of duplicate databases. Internet Request for Comments RFC 677. (January 1976) Information Sciences Institute

[9] Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, and Werner Vogels. 2007. Dynamo: Amazon’s highly available key-value store. ACM SIGOPS Operating Systems Review. 41, 6 (October 2007), 205-220. DOI: https://doi.org/10.1145/1323293.1294281

[10] Seth Gilbert and Nancy Lynch. 2002. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News. 33, 2 (June 2002), 51-59. DOI: https://doi.org/10.1145/564585.564601

[11] Alibaba 2020. Constraints on using the active-active geo-replication of ApsaraDB for Redis. Alibaba. Retrieved November 1, 2020 from: https://help.aliyun.com/document_detail/71883.html?spm=a2c4g.11186623.2.15.240c4c07jsXWWr#concept-cbs-dfk-zdb

[12] Redis Labs. 2020. Active-Active Geo-Distribution (CRDTs-Based). Redis Labs. Retrieved November 1, 2020 from: https://redislabs.com/redis-enterprise/technology/active-active-geo-distribution/

[13] SoundCloud 2020. Roshi. SoundCloud. Retrieved November 1, 2020 from: https://github.com/soundcloud/roshi

[14] Marc Shapiro, Nuno Preguica, Carlos Baquero, Marek Zawir ski. 2011. A comprehensive study of convergent and commutative replicated data types. Technical Report. (January 2011)

[15] AntidotDB 2020. AntidotDB. AntidotDB. Retrieved November 1, 2020 from: https://github.com/AntidoteDB/antidote

[16] Riak 2020. Riak KV. Riak. Retrieved November 1, 2020 from: https://riak.com/products/riak-kv/index.html

[17] Microsoft 2020. Azure Cosmos DB: Pushing the frontier of globally distributed databases. Microsoft. Retrieved November 1, 2020 from: https://azure.microsoft.com/en-us/blog/azure-cosmos-db-pushing-the-frontier-of-globally-distributed-databases/

[18] EQ Alpha 2020. Active Replica Setup. EQ Alpha. Retrieved November 1, 2020 from: https://docs.keydb.dev/docs/active-rep/

[19] Redis Labs. 2020. Redis Enterprise Cluster Architecture. Redis Labs. Retrieved November 1, 2020 from: https://redislabs.com/redis-enterprise/technology/redis-enterprise-cluster-architecture/

tecture/

點選關注,第一時間瞭解華為雲新鮮技術~