今天 ob 的同事花了乙個多小時講了 paxos 的原理, 我相信場上聽懂50%的人不超過50%. 至少我自己對 basic-paxos 還存在這幾點疑問.
multi paxos 是不需要 prepare 的, 而 basic paxos 需要, 為什麼多個leader 的時候需要做 prepare 呢?
prepare 階段是用來決定當前要進行 accept 的 proposal id 的. 擁有 prepare 階段後的 accept 階段可以保證很大概率下多數人可以接受它的請求. 如果失去了 prepare 階段, 並且有多個 leader 在同時提交, 很可能出現大家都在做持久化,但是都是一群烏合之眾,沒有乙個人是 majority. 雖然有了 prepare 階段後, 依然可能出現全是烏合之眾的情況, 但是大大降低了.
從 paxos 的推演的角度, 我們來思考這個問題, paxos 需要滿足以下三個原始條件
決議（value）只有在被proposers提出後才能被批准（未經批准的決議稱為「提案（proposal）」）；
在一次paxos演算法的執行例項中，只批准（chosen）乙個value；
learners只能獲得被批准（chosen）的value。
我們怎麼保證只批准乙個 value 呢? 那就是看哪個 value 是多數派,多數派的那個有效. 為了形成多數派, 必然要有一方比另一方至少多1個, 而怎麼保證這1個肯定出現,而不是搖擺不定呢? 所以我們有了約束p1:乙個 acceptor 必須 accept 遇到的第乙個提案
繼續考慮, 條件2其實只說了批准 value, 沒說不能 accept 多個決議. 所以我們有了約束p2:乙個 value 被 批准後, 之後批准的提案必須具有這個 valuep2進一步加強可以得到p2a: 乙個 value 被批准後, acceptor 只能接受具備這個 value 的提案但是p2a不具備可操作性, 與p1矛盾了. 所以我們用 p2b 代替p2b: 乙個 value 被批准後, proposal 只能提出具備這個 value 的提案
到這裡,我突然想通了 prepare 階段是幹嘛的, prepare 階段就是檢查當前有沒有已經 accept的提案的,如果已經有了 accept 的提案, 那麼就不能提出了(如果 value 不同. 如果強行提出呢? 只不過是浪費頻寬罷了
但是故事還沒完, p2b 的意思是, proposal 每提出決議,就要訪問全部其他節點, 看有沒有 value 被批准. 這可太麻煩了. 退化為2pc 了喂! 所以有了非常拗口的p2c: 如果乙個編號為n的提案具有value v，那麼存在乙個多數派，要麼他們中所有人都沒有接受（accept）編號小於n 的任何提案，要麼他們已經接受（accept）的所有編號小於n的提案中編號最大的那個提案具有value v。
從這裡, 我們得到乙個神奇的結論, paxos 是 2pc 的單調遞增優化!
如果我們簡單的把2pc 的 commit 條件設定為多數同意就 commit. 是不是就變得和 paxos 一樣了呢?
2pc 的 commit 條件設定為多數同意, 這就是 zookeeper 的 zab 演算法. 它比 paxos 弱的一點是, 當乙個 acceptor 在 prepare 階段接受了乙個提議後, 除非 rollback, 不然不能接受新的更大的提議, 也就是有個鎖在上面. 而 paxos 協議是可以打破這把鎖的. 打破鎖的行為, 可以提高吞吐量和容錯率. ( 這點不知道線上驗證如何.
在 prepare 和 accept 後都需要持久化, 不過 accept 才是資料持久化.
今天暫時想通了這麼多, 明天繼續和同事切磋去.
對Linux inode的一些理解
檔名 inode device block 一 inode是什麼？理解inode，要從檔案儲存說起。檔案儲存在硬碟上，硬碟的最小儲存單位叫做 扇區 sector 每個扇區儲存512位元組 相當於0.5kb 作業系統讀取硬碟的時候，不會乙個個扇區地讀取，這樣效率太低，而是一次性連續讀取多個扇區，即一次...
對棧的一些理解
之前總結過一篇有關函式棧幀的部落格 函式棧幀以及呼叫約定相關的一些總結 但是感覺自己還是有一點知識點沒有弄懂,今天中午跟郭哥吃過飯一起 有關殼的問題的時候,順便把這個問題請教了一下郭哥,終於弄明白了,在此要特地感謝他,這裡把一些心得體會寫出來 先看一幅圖 選自ida權威指南 注意圖中是基於esp的棧...
對EK的一些理解
首先是網路流問題的提出 乙個源點，乙個匯點，不斷又源點向匯點輸送，其中路徑上有最大速度，求匯點收貨的最大速度是多少。在求之前可以先模擬一下過程如果源點現在只能出乙個單位的貨，那麼他會找乙個未達到最大速度的路進行運輸，接著我們不斷將運輸的量放大，即不斷地從起點開始尋找增廣路，每次都對其進行增廣，直到源...