有關複製方案/算法的文章？

Question

我正在設計一個分佈式系統，其中包含一定數據流。我想保證在任何給定時間至少有N個節點具有近乎當前的數據。 我不需要完整的一致性，只有最終的一致性（在任何時刻t.i.，數據的當前快照最終應該出現在至少N個節點上，這裏很難定義術語「當前」，但仍然）。節點可能會失敗並隨時恢復，並且沒有單個「中央」節點。

O溢出！將我指向一些描述複製方案的優秀論文。到目前爲止，我發現了一個：Consistency Management in Optimistic Replication Algorithms和同一作者的更廣泛和最近的文章：Optimistic Replication。

Answer 1

不RDBMS無關，但SQL Server 2008（2005年起）支持Peer-To-Peer Replication

Answer 2

很多把戲這是找到您的具體要求，以及你的聲音仍然很模糊。你只需要支持這樣的操作？

• 更新密鑰K值V.
• 查一查你提到你需要最終一致性的關鍵K.

有點-最新值。所以如果你進行一次更新，它最終會在任何地方複製。如果你幾乎同時進行兩次更新，你是否關心哪一個獲勝？如果一個副本報告更新已成功完成，那麼您是否在意如果該副本稍後會暫時崩潰，那麼該值是否會丟失？或者如果這個複製品被永久銷燬？

近期應該有多精確？如果存在網格劃分或其他問題，查找可能會返回一個非常陳舊的結果或者只是失敗。你關心哪個？

你是否需要支持像票友操作...

• 獲取密鑰K的絕對是最新的價值？
• 如果最近的值是V，那麼將K的值更新爲V'值？

您是否有嚴格的可靠性，延遲和/或帶寬要求？你的副本有多遠/網絡有多好？這會影響您是否可以在每次更新甚至每次查找時進行跨副本通信;或者即使您可以/應該將操作故障切換到遠程複製副本，如果本地副本出現故障。

根據你在這裏的答案，我已經與一些可能符合你的要求的不同方案合作。他們有幾種可能的變化。

• 最簡單的事情就是讓應用程序始終與本地副本進行通話。副本時間戳記值（使用NTP同步時鐘），並且只能彼此交談以進行異步複製。複製中獲得最高時間戳。當然，如果兩個不同副本上的應用程序每個都同時進行讀取/修改/寫入，則其中一個修改很容易丟失。 （事實上​​，如果沒有條件更新方案，對於同一個副本上幾乎同時發生的更改也是如此）。如果副本永久失敗，則可能會丟失近期更新。這或多或少是Bigtable的內置複製所做的。在你關聯的論文中，這將是「樂觀 - 多頭」分支，但不關心丟失一些更新使得它比他們的建議更簡單。
• 有些數據庫使用的Paxos算法（參見例如，「數據管理互聯網規模的單點登錄」 here使票友的事情成爲可能。每個副本可以知道你怎麼能遠遠落後於它可能是這麼說的「給我這是不超過1分鐘的老」或‘給我的絕對是最新的價值。’更新不被認爲是完整的，直到副本的法定人數已經接受了它，所以‘值給我絕對的最新值’一定會始終返回值，直到另一次更新發生的。你可以做我提到的防止同時從作家流浪對方條件更新操作。這似乎並不完全適合無論是樂觀還是悲觀的類別由作者定義，因爲更新同步複製到這並沒有在最新一輪的Paxos投票的法定人數，但副本可能仍然能夠回答一些疑問，該方案可以很複雜的，但...