paxos日誌回放應該怎樣去做？

01-13

正在做mit6.824 lab3b，現在遇到了一個問題。在用paxos協議做master和slave一致性保證時，先寫put，append，get等日誌，然後redo日誌到資料庫中。那麼問題來了
1、什麼時候redo日誌比較好？是用一個後台線程來做，還是get後觸發。
2、注意到oceanbase是get後觸發，那麼這個觸發怎麼保證在多數伺服器中都寫到資料庫中，還是用paxos嗎？

3、如果還是用paxos，那麼想知道，基本的paxos實現只是將value放到日誌中，怎麼觸發寫資料庫呢？修改paxos協議嗎？

謝邀! 哄娃間歇簡單答一發。

看了問題，覺得應該不是回放，應該是想說日誌同步。

先明確幾個前提吧：

1.get操作不需要記錄redo日誌，只有寫事務操作才需要寫redo日誌。

2.paxos解決的是多機存儲同一個值的一致性問題，在當前這個問題中，這個「值」指的是redo日誌的內容，為了方便指代一個redo日誌，暫且使用連續遞增的log_id來指明不同的redo日誌，那麼問題模型目標簡化為，主備多機中，同一個log_id的日誌內容應該一致，並且，為保證事務的ACID，一旦一個事務提交成功，則保證多數派的Server中一定存在對應redo日誌。

3.oceanbase的redo日誌不能說是「get觸發"這麼簡單。

使用paxos實現主備機日誌日誌同步這個大問題，可以分解為兩個小問題：

1.工程上，如何實現主備機日誌同步？

2.基於問題1的實現基礎，如何實現paxos協議？

先說問題1：

redo日誌持久化存儲成功是事務提交的前提，在事務執行的關鍵路徑上，因此性能至關重要，目前主流技術是採用group commit。

group commit是指讓」一段時間「內的並發執行的事務將redo日誌並發寫到一個buff中，buff寫滿後，將此buff刷盤或者通過網路發給備機，一旦I/0成功，則此buff中所有redo日誌對應的事務都一下子提交成功了。這樣做的好處是，可以利用磁碟設備有限的IOPS(每秒執行的IO次數），實現事務最大的並發量。在oceanbase中，這個buff就是2MB。

實現上，為了實現高性能，要盡量避免有線程任務太重成為瓶頸，又要避免多線程均攤任務以致出現的過度鎖爭用問題，拋出一個可能的解決方案吧：全局一個buff，多個線程執行事務，事務提交前，多個線程都並發的將redo日誌拷貝到全局buff中，如果有某個線程發現buff已經寫滿，則將這個buff提交給一個刷盤線程，刷盤線程只管執行I/O。當然，這個只是解決問題的思路的開始，後面要解決一系列資料庫的事務約束的問題，不細說了。

問題2：

paxos解決資料庫redo日誌實在比較複雜，目前似乎只有google spanner和megastore這麼做了，當然，oceanbase也這麼做了。

傳統paxos允許多個proposer（可能有衝突），而且一個決議至少需要4次通信才能確定，這在工程實現上是無法接受的，multi-paxos應運而生。

使用multi-paxos時，假設有了一個leader(假設有了一個靠譜的選主協議），這個leader只需要一次prepare[local_max_commit_log_id, 無窮大）這個區間的所有log_id，成功後，後面只需要發送accep請求就好了，備機批准accept請求也可以一次批准多個redo日誌，相比於paxos，性能大大提升了。

要想實現一個工程上可用、基本正確的multi-paxos協議，真的太難了，對於大部分需求，raft足夠了，沒有必要再造一個漏洞百出的輪子了。

說的比較簡略，歡迎大家批評討論。

謝邀正好最近在寫一篇Paxos的博客，今天剛寫完，請參考吧

使用Multi-Paxos協議的日誌同步與恢復 - 分散式與存儲技術 - 知乎專欄

paxos演算法不考慮單個節點如何持久化日誌，這應該取決於不同的實現，只要實現能夠滿足一定的標準，比如成功accept就意味著該操作已經被成功記錄下來了。對於日誌redo的問題，取決於實際需求吧，本來paxos演算法就不對單個節點availability有要求，就算日誌丟了也沒問題，所以非同步是可以的，也可以設置一個threshold觸發時才去寫。

沒讀過基於paxos實現的代碼，這裡打個廣告，可以參考下 https://github.com/baidu/ins，基於raft的。