下圖是基本的Paxos的消息流,在相位2a中,組長選擇值Vn其proposal1併發送接受!(1,VN)的每一個受體。我的問題是:如果三條消息中的兩條丟失了,該怎麼辦?我的意思是隻有接受者1(不是多數)接受接受!(1,Vn)。受讓人1會接受這個請求嗎?然後播放給每個學習者?這個值是選擇? 的Paxos階段2a消息丟失
4
A
回答
2
提議者沒有得到足夠數量的接受答覆(讀數爲法定人數),因此整個回合失敗。
3
的Paxos是容忍重複消息,因此它是安全的,最佳的,對於投保人重新發送或者準備或接收消息,如果它沒有得到大多數迴應。假設有一個短暫而短暫的網絡問題,只有那些信息丟失了。如果響應超時,然後重新發送消息,則消息將通過,並且該回合可以成功。這比由於丟失信息而失敗並開始新一輪更有效。
編輯我要指出,作爲@Rakis的評論指出,其實我在談論的Paxos的實際應用,而不是其目的是爲了證明該方法的正確性算法的理論描述。如果有人正在對該主題進行考試,則堅持學術描述。如果您實際上正在編寫an implementation,則超時和重新發送是由於瞬時消息丟失而有效處理丟失的消息的方式。
編輯的回答「全面失敗」意味着有通過啓動新一輪採取行動這一事實超時。超時在文件Paxos Made Simple中未實際提及。因此,如果有人想堅持算法的學術描述,那麼消息丟失的確切答案是「世界停止時沒有任何事情發生」。請注意,該文件表示它不會及時發佈事件,只會導致不會出現不正確的結果。顯然沒有合理的實施將只會無所作爲;它應該超時並且做一些事情。這突出表明了該算法的學術描述僅用於證明正確性的事實;它故意忽略瞭如何使用該算法實際構建實際解決方案的實際考慮。該文件暗示說,您可以添加諸如負面響應之類的內容,以幫助構建實用的實現而不會影響正確性。所以像trex這樣的實用解決方案會返回否定確認,以加快使用該算法的故障恢復恢復。然後沒有得到迴應與獲得否定回答不一樣;所以在消息丟失的情況下,輪次不會失敗,但它有一個不確定的結果。進一步的消息(重新發送)可以安全地發送以確定實際結果。
相關問題
- 1. Paxos vs兩階段提交
- 2. 爲什麼Paxos是兩個階段
- 3. Websockets消息丟失
- 4. Spring JMSTemplate - 丟失的消息
- 5. RabbitMQ中的消息丟失
- 6. 芹菜和丟失消息
- 7. linphone SIP消息丟失
- 8. RabbitMQ正在丟失消息
- 9. Android C2DM消息丟失了?
- 10. 接收udp消息丟失
- 11. lua_pcall錯誤消息丟失
- 12. PostMessage的偶爾丟失的消息
- 13. PHP - 自動更新階段消息
- 14. TabBar在程序化階段消失
- 15. AttributeError和丟失的異常消息
- 16. 如何控制nServicebus丟失的消息
- 17. Symfony的1.4閃存消息丟失
- 18. MSMQ丟失的第一條消息
- 19. 使NServiceBus丟失消息的東西
- 20. 只顯示消息:項目階段[開發]:未處理消息
- 21. ZeroMQ PUSH/PULL並丟失消息
- 22. RxJava異步訂閱將丟失消息
- 23. 重新配置NServiceBus丟失消息
- 24. websocket消息是否會丟失?
- 25. Node.js redis pub/sub丟失消息
- 26. MSMQ私人隊列消息丟失
- 27. ROS用戶回調丟失消息
- 28. java堆空間和消息丟失
- 29. Websphere MQ和mule避免消息丟失
- 30. 超過MSMQ限額 - 消息丟失
應該避免接受第一不正確的答案,只是因爲這是你所期望的答案。 – simbo1905
JensG的回答是正確的。基本的Paxos算法沒有負面響應的概念,因此缺少響應被解釋爲否定確認。 Simbo1905的答案也是正確的,但是引用了超出核心算法要求的實際擴展。純算法的優點是它避免了現實世界實現中涉及的大部分複雜性。在實際實施中有效檢測和處理這些故障情況可能相當複雜和具有挑戰性。所以,在第一次學習Paxos時最好忽略這些細節。 – Rakis
@Rakis加上你認真的評論。我已經編輯了我的答案,明確表示它將幫助用paxos構建真正的解決方案,而不是通過關於該主題的cs考試。在我實施paxos的經驗中,我發現使用不實用的合成單輪協議來證明正確性的學術方法可能是人們感到困惑和複雜的主要原因。所以即使它不會幫助任何人通過大學筆試,我也會離開我的實際幫助答案。 – simbo1905