有人可以給我一個Paxos真實用例的列表。這是需要達成共識的真正問題，作爲更大問題的一部分。何時使用Paxos（真實的實際用例）？
以下是Paxos的用例嗎？
假設有兩個客戶在撲克服務器上互相玩撲克。撲克服務器被複制。我對Paxos的理解是，它可以用來保持代表當前撲克牌手的內存數據結構的一致性。也就是說，確保所有副本都具有完全相同的內存狀態。
但爲什麼Paxos是必需的？假設需要處理一張新卡。如果一切正確，運行相同代碼的每個副本將生成相同的卡。爲什麼客戶端無法從所有複製服務器請求最新狀態，並選擇出現最多的卡。因此，如果一臺服務器發生錯誤，客戶仍然會從僅選擇多數的情況下獲得正確的狀態。
另一個現實生活用例是RavenDB處理選擇主節點，http：//ayende.com/blog/4824/raven-situational-awareness – 2011-06-03 11:18:45
這些不是問題或用例，而是Paxos實現或解決方案。 – 2012-05-15 09:03:24
Zookeeper不使用Paxos，它實際上使用Zab [1]。 1. Zab描述於Benjamin Reed 和Flavio Junqueira（LADIS '08：Proceedings of the 2nd Workshop on Large-Scale Dis- tributed Systems and Middleware，1-6 pages）中的「簡單完全有序的廣播協議」紐約，紐約州，美國，2008年。ACM） – 2012-11-07 16:00:28
在你描述的情況下，你是對的，Paxos並不是非常必要的：一箇中央機構可以爲甲板生成一個排列並在開始時分發給每個人。事實上，對於一般的撲克遊戲，在撲克中存在嚴格的轉向順序和單個主動玩家的情況下，我看不到您可能需要使用Paxos的合理情況，除了可能選擇中央當局洗牌甲板。
一個更好的例子可能是一個同時進行的遊戲，比如Jeopardy。在這種情況下，Paxos將允許所有服務器一起決定發生什麼序列的一系列緊時間事件（例如蜂鳴器按下），以便所有服務器都得出相同的結論。
等待如果我添加額外的約束，結果需要歸檔到某種永久記錄系統。假設日誌記錄系統是一個SQL數據庫。因此，整個手牌歷史需要存儲到SQL數據庫中，每個玩家的錢也需要在SQL數據庫中更新。在沒有Paxos而只是複製服務器的情況下，如何能夠容忍這種日誌記錄。似乎試圖只依賴其中一臺服務器來寫入SQL數據庫將容易導致一臺服務器崩潰。 – user782220 2011-06-03 07:37:31
@ user782220如果您使用的是SQL數據庫，則需要依賴其複製 - 如果有的話 - 可能使用或不使用paxos。但是，如果您正在構建自己的系統來跟蹤交易，並且您希望它成爲多主人，那麼您可能會希望使用Paxos。 – 2011-06-03 08:14:28
什麼意思是依靠SQL數據庫的複製？是不是依靠一些主SQL數據庫的複製危險？它依賴於主數據庫，其中只有一個數據庫不會被破壞。這不是天生不容錯誤的。 – user782220 2011-06-03 08:27:16
的Paxos用於Subversion版本庫的基於WAN的複製和由Hadoop的NameNode的高可用性我工作的公司（WANdisco plc。）
假設所有的服務器彼此同步（即具有相同的狀態），所以當服務器需要選擇下一張卡時，每個服務器將選擇完全相同的卡（假設你的代碼是確定性的）。
但是，您的服務器的狀態還取決於用戶的操作。例如，如果用戶決定增加50美元 - 您的服務器需要在某處存儲該信息。現在，假設你的服務器向web客戶端回覆了「ok」（我假設一個基於web的撲克遊戲），然後服務器崩潰了。您的其他服務器可能沒有關於50美元加註的信息，並且您的系統不一致（客戶認爲提高了50美元，而存活的服務器卻不知情）。
請注意，由於數據丟失，大多數人在這裏沒有幫助。此外，假設代替主服務器崩潰，主服務器加上另一個服務器獲得了50美元的增加數據。在這種情況下，使用大多數可能會更糟：如果您從兩臺服務器獲得數據響應，您會認爲已執行50美元的加註。但是如果其中一個失敗了，那麼你將不會獲得多數，你會認爲這個提高沒有被執行。
通常，Paxos可用於以容錯方式複製狀態機。其中「狀態機」可以被認爲是具有某種初始狀態的算法，並且其根據從外部（即，網絡客戶端）接收的消息確定性地推進狀態。
更正確，Paxos的應被視爲一個分佈式日誌，你可以閱讀更多關於它在這裏：Understanding Paxos – Part 1
更新2018： Mysql的高可用性使用的Paxos：https://mysqlhighavailability.com/the-king-is-dead-long-live-the-king-our-homegrown-paxos-based-consensus/
現實世界的例子：
Cassandra uses Paxos確保連接到不同羣集節點的客戶端可以安全地通過添加「IF NOT EXISTS」來執行寫操作。 Cassandra沒有主節點，因此可以在多個節點上同時發出兩個衝突的操作。當使用if-not-exists語法時，使用paxos算法來排序機器之間的操作，以確保只有一個成功。客戶可以使用此功能store authoritative data with an expiration lease。只要大多數Cassandra節點都啓動了，它就可以工作。因此，如果您將您的密鑰空間的複製因子定義爲3，那麼1節點可能會失敗，5然後可能會失敗，等等。
對於正常寫入Caassandra允許多個衝突寫入被可能是臨時的不同節點接受無法溝通。在這種情況下，如果兩個Writes同時發生在同一個密鑰上，則不使用Paxos can loose data。 Cassandra中內置的特殊數據結構不會丟失只能插入的數據。
撲克的Paxos：
至於其他的答案注意撲克是基於轉，有規矩。如果您允許一個主副本和多個副本，那麼主控仲裁下一個操作。比方說，用戶首先點擊「檢查」按鈕，然後改變主意並點擊「摺疊」。那些相互矛盾的命令只有第一個應該被接受。瀏覽器不應讓他們按第二個按鈕，當他們按下第一個按鈕時，它將會禁用它。由於涉及金錢，主服務器也應該執行規則並且只允許每個玩家每回合一次動作。當遊戲中主人崩潰時，問題就出現了。哪個副本可以成爲主人，以及如何強制只有一個副本成爲主人？
處理選擇新主人的一種方法是使用外部強一致服務。我們可以使用Cassandra來爲主節點提供create a lease。副本可以在主服務器上超時並嘗試獲取租約。由於Cassandra使用Paxos，它具有容錯能力;即使Cassandra節點崩潰，您仍然可以讀取或更新租約。
在上面的例子中，撲克大師和副本最終是一致的。主人可以發送心跳信號，以便副本知道他們仍然連接到主人。隨着消息朝一個方向流動，這很快。當主人崩潰時，可能會有副本試圖成爲主人的競爭條件。在這一點上使用Paxos可以一致地強調哪個節點現在是主節點的結果。這需要節點之間的附加消息來確保單個主機的共識結果。
這對撲克服務器來說是一種矯枉過正，除非你要舉辦世界撲克錦標賽。 :) – 2011-06-03 05:39:44