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進行分割槽，相同使用者的所有操作都進入同乙個分割槽，也就達到了順序性。
當然，有順序也是有害處的，有順序就意味著阻塞，如果消費一條訊息一直失敗，消費過程會受到阻塞，靈活的處理方式是重試到一定次數，把這條訊息持久化到遠端，跳過這條訊息繼續消費。也就意味著失去了順序。
kafka 為什麼快
一般的 mq 每個訊息都有乙個狀態，這樣每個訊息狀態改變都要更新，增加了很多隨機讀寫。kafka 對每個 partition 只有乙個指標，而不是儲存每個訊息的狀態，所有在指標後面的訊息都是被消費過的訊息。這就去掉了很多 確認訊息 動作的隨機讀寫，通過一次移動指標，來確認多個訊息。很多訊息中介軟體，...
kafka系列4 什麼是kafka
關於什麼是kafka，看過乙個簡單例子。舉個例子，生產者消費者，生產者生產雞蛋，消費者消費雞蛋，生產者生產乙個雞蛋，消費者就消費乙個雞蛋，假設消費者消費雞蛋的時候噎住了 系統宕機了 生產者還在生產雞蛋，那新生產的雞蛋就丟失了。再比如生產者很強勁 大交易量的情況 生產者1秒鐘生產100個雞蛋，消費者1...
為什麼要使用Kafka？
我們在學習乙個東西的時候，往往只有真正了解它背後的含義，才能一步一步的掌握它，直到運籌帷幄。對於kafka來說，我也是乙個小白，本篇文章我就以乙個小白的角度來初探一下kafka，本篇文章基於官方文件，順便說一句官方文件真的很重要，且讀且珍惜。kafka最早是由linkedin公司開發的，作為其自身業...