知乎使用者2017-08-22 16:23:40這個系統的熱度最近也降下來了，最近比較忙，一直沒更新。之前的回答不好，給刪了。寫了幾個點，水平不高，肯定有錯，希望不要責怪，討論為上。
效能
write latency 在 10ms 以下，和我們的 pegasus 差不多。更多時候在 8ms 以下。這類系統都差不多，將分散式讀寫透過雜湊直接 route 到某一節點，請求不經中轉直接到機器上，效能大體都是這樣吧。
fault tolerance 相關的時間沒有評估，估計是不錯的。
paxos
做這個系統最重要莫過於 paxos。當時看了 paxosstore team 的分享 ppt，有張圖讓我覺得很不可思議。
這張圖我認為有點用力過猛了。看過 paper 的應該都會對這個
切換不可用期（無）
有一個比較客觀的評價。
paxoslog-as-value
我不知道有哪個系統使用了類似機制，感覺不錯。
我自己的思路是這樣的：有時候為了圖簡單（或者工期緊），會把 raftlog/paxoslog 寫到 leveldb（index 是 key，log entry 是 value），寫完 wal 以後，資料也寫到 leveldb，這麼搞就要寫兩遍 leveldb，冗餘太多效能肯定是不行的。
對這個問題 paxosstore 想了一個最佳化，就是 key -> log entry 的形式，寫日誌即寫資料。
這個點我們可以套用在 raft 試試（講 raft 是因為可以使用在 raft 裡定義的名詞）∶
對於 committed log，把日誌寫到 leveldb 是合適的，因為一致性協議不會再需要 log index 了。而 uncommitted log 要專門寫，用最簡單的 index -> log 的方式。
有人可能會想這跟 raft snapshotting 有什麼區別？其實沒什麼區別，只是 log compaction 從 snapshotting 改成 lsm 而已。
實現
（paxosstore 有開源，大家有興趣可以去看 ）
不想吐槽，有相關經驗的同學應該都能辨別，反正看了之後我覺得挺無奈的。
工人萬歲2017-08-24 22:55:47先佔坑
掃了下Paxos的部分，兩個特點：
1、 去中心化，感覺這樣會有活鎖
2、沒有采用多數Paxos系統prepare ack 訊息介面，統一使用遠端呼叫，不區分訊息型別。省了狀態機的維護，簡化了過程。感覺這個設計還是很巧妙的。
感覺issue（p）的發起和value的commit寫的不是特別清楚，不知道是不是我理解的不對。
看起來是節點A將編號為m的提議RPC廣播，各個節點獨立檢查提議m的狀態，如果本地狀態相較和來自節點A的狀態相比更新，則通知A。否則什麼都不做。節點A統計遠端呼叫結果，如果有超過半數的節點“什麼都不做”，可以發起Issue（p），廣播value
commit部分，貌似仍然是由節點A發起一個RPC統計各個節點上統計提議出現最多次數的value的次數，弱超過半數，則在該節點提交。。。。
希望有大神來解惑
匿名使用者2017-09-02 10:42:56哈哈 VLDB現場照片
吳鏑2018-05-04 19:41:41今天粗略看了下相關論文文件和程式碼paxoskv（沒有看certain，這裡只描述paxoskv），發現這個東西和我想象中的差別還是非常大的。。（沒看完整，有錯請指正）
看上去只是實現了一個針對KV場景最佳化後的支援強一致性的系統，程序啟動的時候需要指定好paxos group（內的機器地址），這個系統本身是不能自動擴容的（加入機器，啟好程序，然後資料就開始自動進行搬遷，rebalance了），所以本質上還是一個靜態的系統，不能像fdb/TiKV等系統一樣，自動將table拆成region，region合併，region在node之間遷移。可以認為這個系統實際上只能容納一個region，這個region的容量和磁碟大小有關。
創新點在於：
log中的entry會儲存一個data的最終資料，而不是增量資料，所以有些操作需要把資料先讀上來再寫下去，比如+1操作。
處理讀請求不是基於paxos自己的機制，而是在這個之上，自己搞了一套類似於quorum的讀協議。
單機的那個引擎可插拔，感覺這個優點不算什麼。
如果要真正的用起來的話，還得自己再這個東西的上面再搞一個套sharding的方案，比如一致性hash，然後還要涉及到資料遷移。
感覺這套東西外面的公司要用起來難度還是非常大的。
之前一直以為這東西是實現了分散式的可自動擴容的強一致的KV。
