回答幾個網友提出的問題，不清楚的可以看上一篇內容。

1、  kafka的刪除策略應該怎麼配置？為了提升效能，我是不是應該1小時刪除一次消費過的資料。

完全可以根據磁碟大小配置，只要磁碟足夠用，完全沒必要刪除的那麼著急。Kafka的吞吐量不會因為資料量的增長而降低。因為讀寫資料時，kafka完全是順序的，只記錄offset，時間複雜度是O（1），我曾經測試過上T的資料，完全不受影響。反倒是資料刪除的太快，容易造成資料丟失。

2、  訊息傳送一直失敗，到達了指定重試次數怎麼處理？

客戶端可以設定重試次數和重試間隔時間，因為一般kafka是以叢集形式存在的，一直重試都不能成功，並不多見，常見的情況是應用和kafka

叢集斷網。實際上在重試的過程中，如果應用掛掉，這個訊息就丟失了，如果要避免此種情況發生，需要持久化訊息，當然可以選擇本地持久化和遠端持久化，選擇本地持久化也不是非常安全，因為現在的應用伺服器很有可能是虛擬機器或者容器，遠端持久化相對安全。但是遠端意味著需要網路，如果恰巧遠端持久化也失敗，該怎麼辦？解決此類問題，最後的救命稻草就是日誌。這類問題並不只是在mq中，入庫也是一樣，分散式場景中非常常見，但是因為發生的概率不大，通常都被開發人員忽略。這也就是做結算的永遠都不能把賬算平的原因所在。通常要權衡處理這樣的小概率事件是不是值得。重要的系統通常有定時檢查的功能。作為小概率事件的事後補償機制。

3、

  如果總副本數為f，最多允許丟失多少副本？

最多允許丟失f-1個副本，也就是隻要有一個副本就沒問題。當然這和broker的配置有關。從服務端角度，如何儘快將更新後的資料分佈到整個系統，降低達到最終一致性的時間視窗，是提高系統的可用度和使用者體驗非常重要的方面。對於分散式資料系統：

a)         N — 資料複製的份數

b)         W — 更新資料是需要保證寫完成的節點數

c)         R —

讀取資料的時候需要讀取的節點數

任何一個分散式系統，在服務端，要想保持強一致性，必須符合W+R>N，也就是說，假設一共有3個節點，寫資料的時候，三個節點都寫入成功才返回，只要有一個節點存活，就能保證資料是最新的。

 

4、  Kafka是有順序的嗎？

在同一個partition完全是有順序的，生產者可以設定分割槽策略，可以自定義分割槽策略，這樣就可以根據業務分割槽。舉個例子，如果是跟使用者相關的，完全可以根據使用者id進行分割槽，相同使用者的所有操作都進入同一個分割槽，也就達到了順序性。

當然，有順序也是有害處的，有順序就意味著阻塞，如果消費一條訊息一直失敗，消費過程會受到阻塞，靈活的處理方式是重試到一定次數，把這條訊息持久化到遠端，跳過這條訊息繼續消費。也就意味著失去了順序。