文章插圖
這次，我們站在上帝視角，讓聽眾2改變一下選擇 ， 既然話務員2已經被別人收買了，那么干脆避其鋒芒，直接向話務員1、3報價 。
文章插圖
可想而知，聽眾2的報價會被兩位話務員都認可 。
文章插圖
在收到了半數以上話務員的報價認可后，聽眾2先向話務員1發起點歌請求 。
文章插圖
話務員1比對一下報價，嗯，沒有問題 ， 更新本地的記錄，接受他的點歌請求 。
文章插圖
講道理，現在的形勢對聽眾2真的是一片大好 ， 只要再打個電話給話務員3，就能夠成功點歌了 。
但是這個節骨眼上，聽眾2的室友喊他了，說：聽歌多沒意思，咱們一起來打一局刀塔吧 。
聽眾2一想，沒毛??，那蜗伻矇你歌?。
而這時，聽眾1回過神來了，他在之前報價階段可是獲得過半數以上的認可的 ， 于是他帶著之前被認可的報價打電話進來點歌 。
文章插圖
可是在兩位話務員那里，記錄的最高報價已經升到了兩塊了，于是聽眾1的點歌請求會被拒絕 。
文章插圖
到這 ， 我們梳理一下，聽眾1的點歌請求得到了1個接受、2個拒絕 ， 也就是說他的提議沒有被過半數以上的話務員接受 。
無奈，聽眾1只能回到第一階段 ， 從報價開始再重頭走一遍流程 。并且這次，他把報價提升到了3塊 。
文章插圖
三位話務員收到新的報價請求后，都會表示認可，并且返回自己本地記錄的信息 。
文章插圖
聽眾1這一次收到的三條報價認可中，有兩條攜帶了之前被接受的點歌信息 。那么新問題來了 ， 他應該選哪一首歌曲作為自己接下來要點播的歌曲呢？
在這里，聽眾要遵循的規則其實和話務員一致，他需要在這些返回的報價及歌曲信息中，選擇最高報價的歌曲，作為自己的接下來選歌的依據，因此他最終會選擇《簡單愛》 。
文章插圖
最終，在沒有其他聽眾中途打進電話干擾的情況下 ， 三位話務員都會接受聽眾1的點歌請求 。
文章插圖
最終，聽眾1的點歌請求收到超過半數話務員的接受，于是他確認《簡單愛》這首歌會被選中 。
最后前面提到過，Paxos算法中的選舉過程就像是一場博弈，場上局勢瞬息萬變 。
回顧一下上面3條不同的時間線，打進電話順序的不同、選擇的話務員不同，都可能導致最終產生不同的結果 。
而Paxos算法本身，并不關注最終選擇的是哪一個結果，它關注的是無論如何，在最后一定要能夠達成一個共識 。
當然了，也有可能遇到下面這種無法解決的情況…
文章插圖
文章插圖
在這種情況下 ， 可能會有兩個聽眾交替報價成功，卻提議歌曲失敗 ， 形成一個活鎖的局面 。如果這樣下去，有可能一整天下來，一首歌曲都沒有被最終選取成功 。
所以在某些情況下，需要選取一個主提案者，只有主提案者才能和過半的接受者進行通信提出提案 。
說白了，也就是我們常說的話事人 。
文章插圖
那么 ， 我們最后再做一個總結，其實在我看來，Paxos算法的關鍵，就在于后者要認同前者，來避免無休止的爭端 。
本文也只是對決議部分的兩階段通過示例進行了說明，并忽略了算法中另一個角色學習者的內容，如果有興趣的話，大家不妨去看看論文原文 。
畢竟蘭伯特大佬都說了：
文章插圖
推薦閱讀
- SpringCloud整合分布式事務Seata 1.4.1 支持微服務全局異常攔截
- 穿越火線CF怎么改名呢（cf昵稱被系統強制改名了)
- MassTransit | .NET 分布式應用框架
- 齊博X1-欄目的調用1
- 云原生分布式 PostgreSQL+Citus 集群在 Sentry 后端的實踐
- 微服務系列之分布式日志 ELK
- 華為手環6是什么系統_華為手環6是鴻蒙系統嗎
- Blazor組件自做十一 : File System Access 文件系統訪問 組件
- ios14.6耗電怎么樣_ios14.6系統耗電情況
- 谷歌新AI系統Imagen有點強，輸入文本就能生成逼真的圖像