Paxos 的真實世界示例

Question

有人能給我一個真實世界的例子，說明 Paxos 算法是如何在分布式數據庫中使用的嗎？ 我已經閱讀了許多關於 Paxos 的論文，它們解釋了算法，但沒有一篇真正用實際例子來解釋。

一個簡單的例子可能是一個銀行應用程序，其中一個帳戶通過多個會話被修改（即在櫃員處存款、借記操作等）。 Paxos 是用來決定哪個操作先發生的嗎？ 另外，Paxos 協議的多個實例是什么意思？ 這個什么時候用？ 基本上，我試圖通過一個具體的例子而不是抽象的術語來理解這一切。

Answer 1

例如，我們有 MapReduce 系統，其中 master 由 3 個主機組成。 一個是主人，一個是奴隸。 選擇master的過程使用Paxos算法。

此外，Google Big Table的 Chubby使用 Paxos：松耦合分布式系統的 Chubby 鎖服務， Bigtable：結構化數據的分布式存儲系統

Answer 2

Clustrix數據庫是一個分布式數據庫，在事務管理器中使用 Paxos。 數據庫內部使用 Paxos 來協調消息並維護分布式系統中的事務原子性。

• 協調器是發起交易的節點
• 參與者是代表修改數據庫的節點
• 交易讀者是代表交易執行代碼但沒有修改任何狀態的節點
• 接受者是記錄交易狀態的節點。

執行事務提交時采取以下步驟：

1. Coordinator 向每個 Participant 發送 PREPARE 消息。
2. 參與者鎖定交易狀態。 他們將 PREPARED 消息發送回協調器。
3. Coordinator 向 Acceptor 發送 ACCEPT 消息。
4. 接受者記錄成員身份、交易、提交 id 和參與者。 他們將 ACCEPTED 消息發送回協調器。
5. 協調器告訴用戶提交成功。
6. Coordinator 向每個 Participant 和 Reader 發送 COMMIT 消息。
7. 參與者和讀者提交交易並相應地更新交易狀態。 他們將 COMMITTED 消息發送回協調器。
8. 協調器刪除內部狀態，現在完成。

這對應用程序來說都是透明的，並在數據庫內部實現。 因此，對於您的銀行應用程序，所有應用程序級別需要做的就是對死鎖沖突執行異常處理。 大規模實現數據庫的另一個關鍵是並發性，這通常通過 MVCC（多版本並發控制）提供幫助。

Answer 3

有人能給我一個真實世界的例子，說明 Paxos 算法是如何在分布式數據庫中使用的嗎？

MySQL 使用 Paxos 。 這就是高可用 MySQL 設置需要三台服務器的原因。 相比之下，典型的 Postgres 設置是不運行 Paxos 的主從雙節點配置。

我已經閱讀了許多關於 Paxos 的論文，它們解釋了算法，但沒有一篇真正用實際例子來解釋。

這里是對 Paxos 進行事務日志復制的相當詳細的解釋。 這是在 Scala中實現它的源代碼。 Paxos（又名 multi-Paxos）在消息方面是最高效的，就像在三節點集群中一樣，在穩定狀態下，領導者接受自己的下一個值，傳輸到其他兩個節點，並且知道該值是固定的得到一個回應。 然后它可以將提交消息（學習消息）放在它發送的下一個值的前面。

一個簡單的例子可能是一個銀行應用程序，其中一個帳戶通過多個會話被修改（即在櫃員處存款、借記操作等）。 Paxos 是用來決定哪個操作先發生的嗎？

是的，如果您使用 MySQL 數據庫集群來保存銀行賬戶，那么 Paxos 將用於確保副本與主服務器就交易應用於客戶銀行賬戶的順序達成一致。 如果所有節點都同意應用交易的順序，它們都將持有相同的余額。

如果不提出可能違反不超過您的信用的業務規則的不同余額，則無法重新訂購銀行帳戶的操作。 確保順序的一種簡單方法是僅使用一個服務器進程，該進程僅根據它收到的消息的順序來決定正式的順序。 然后它可以跟蹤每個銀行賬戶的余額並執行業務規則。 然而，您不希望只需要一台服務器，因為它可能會崩潰。 您希望副本服務器也接收信用和借記命令並同意主服務器。

擁有應該保持相同余額的副本的挑戰是消息可能會丟失並重新發送，並且消息會被交換機緩沖，這些交換機可能會延遲交付一些消息。 最終效果是，如果網絡不穩定，則很難證明快速復制協議永遠不會導致不同的服務器看到消息以不同的順序到達。 您最終將在同一個集群中擁有不同的余額的不同服務器。

您不必使用 Paxos 來解決銀行賬戶問題。 你可以做簡單的主從復制。 您有一個主站，一個或多個從站，主站會等待，直到收到從站的確認，然后再告訴任何客戶端命令的結果。 那里的挑戰是丟失和重新排序的消息。 在 Paxos 被發明之前，數據庫供應商只是創建了昂貴的硬件，旨在具有非常高的冗余和可靠性來運行主從。 Paxos 的革命性之處在於它可以使用商品網絡，無需專業硬件。

由於銀行應用程序可以通過昂貴的定制硬件獲利，因此許多現實世界的銀行系統很可能仍在以這種方式運行。 在這種情況下，數據庫供應商通過內置的可靠網絡為專業硬件提供運行數據庫軟件的網絡。 這是非常昂貴的，不是小公司想要的。 注重成本的公司可以在具有正常網絡的任何公共雲中的 VM 上設置 MySQL 集群，Paxos 將使其可靠，而不是使用專業硬件。

另外，Paxos 協議的多個實例是什么意思？ 這個什么時候用？

我寫了一篇關於 multi-Paxos 作為原始 Paxos 協議的博客。 簡單地說，在選擇集群中事務順序的情況下，您希望將事務作為值流進行流式傳輸。 每個值都固定在協議的單獨邏輯實例中。 正如我在關於用於集群復制的Paxos 的博客中所述，該算法在穩定狀態下非常有效，只需要在主節點和足夠多的節點之間進行一次往返即可擁有大多數節點，即三節點集群中的另一個節點。 當出現崩潰或網絡問題時，算法總是安全的，但需要更多消息。 所以要回答你的問題，典型的應用程序需要多輪 Paxos 來建立集群中客戶端命令的順序。

需要注意的是，Raft 是專門為詳細描述如何執行集群復制而發明的。 最初的 Paxos 論文要求您弄清楚許多細節才能進行集群復制。 所以我們可以期待那些專門嘗試實現集群復制的人會使用 Raft，因為它沒有讓實現者自己弄清楚。

那么什么時候可以使用Paxos呢？ 它可用於更改基於不同協議寫入值的集群的集群成員資格，該協議只有在您知道確切的集群成員資格時才能正確。 Corfu就是一個很好的例子，它通過讓客戶端同時寫入服務器分片來消除通過單個 master 寫入的瓶頸。 然而，只有當所有客戶端都准確了解當前集群成員和分片布局時，它才能准確地做到這一點。 當節點崩潰或您需要擴展集群時，您建議一個新的集群成員資格和分片布局，並通過 Paxos 運行它以在整個集群中達成共識。

Answer 4

Raft是一種共識算法，旨在易於理解。 它在容錯性和性能上與Paxos相當。 不同之處在於它被分解為相對獨立的子問題，並且它干凈地解決了實際系統所需的所有主要部分。 通過邏輯分離， Raft比Paxos更易於理解，但它也被正式證明是安全的，並提供了一些額外的功能。 Raft 提供了一種跨計算系統集群分發狀態機的通用方法，確保集群中的每個節點都同意相同的一系列狀態轉換

筏上的實際用途

etcd是一種高度一致的distributed key-value store ，它提供了一種可靠的方式來存儲需要由分布式系統或機器集群訪問的數據。 它在網絡分區期間優雅地處理領導者選舉，並且可以容忍機器故障，即使在領導節點中也是如此。 任何復雜的應用程序，從簡單的 Web 應用程序到Kubernetes ，都可以從Kubernetes讀取數據並將數據寫入到 etcd。

etcd 是用 Go 編寫的，它具有出色的跨平台支持、小型二進制文件和背后的強大社區。 etcd 機器之間的通信是通過 Raft 共識算法處理的。