紅色為：leader。青色為：follower。黑色為：宕機。黃色為：恢復。
資料1 寫入 broker1,broker2,broker3。完成提交所以這裡的順序不是資料傳送順序。資料2進行寫操作，leader寫入後宕機（還有沒對副本進行同步），資料2 進行retry。
此時broker2 （replica) 已經變更為leader。
寫入資料3成功（broker2，broker3同步完成）。
broker1嘗試恢復。
broker1恢復成功，需要從同步成功的offset起，truncate所有資料。
broker1(replica)與leader進行同步。
資料2 retry成功。此時的資料的順序就是132。
kafka如何保證資料的順序消費
一公尺多的李同學 最後發布於2019 05 22 20 49 58 閱讀數 5619 收藏 14 展開在對kafka的理解中，常常會被問及到kafka如何保證資料的順序消費 kafka的資料重複消費怎麼處理 如何保證kafka中資料不丟失？今天先說說資料的順序消費問題。關於順序消費的幾點說明 kaf...
kafka順序寫入 ZeroCopy
1.為何kafka把訊息存在磁碟上，但可以輕鬆支援每秒百萬級的寫入請求 kafka高吞吐率的原因？kafka為了防止丟失資料，將收到的訊息寫入磁碟中，但仍能保證高吞吐率，超過了大部分的訊息中介軟體，使得kafka在日誌處理等海量資料場景廣泛應用。為了優化寫入速度kafka採用了順序寫入和mmfile...
kafka保證訊息順序性
順序保證 kafka 可以保證同乙個分割槽裡的訊息是有序的。也就是說，如果生產者按照一定的順序傳送訊息，broker 就會按照這個順序把它們寫入分割槽，消費者也會按照同樣的順序讀取它們。1.單分割槽 2.如果把 retries 設為非零整數，必須把 max.in.flight.requests.pe...