問題：kafka是當下流行的高併發訊息中介軟體，能夠高效並實時的吞吐資料，而且通過副本冗餘機制保證了資料安全。
但還是會出現 丟包 or 重複消費 問題
建立主題時，就已經指定了分割槽數 和 副本數
sh kafka-console-producer.sh --broker-list ip:port --topic topic_name
|—— producer根據指定的partition方法(round-robin hash),將訊息發布到指定topic的partition裡面
2.1 查詢: producer從zk的/brokers/..state節點中查詢該分割槽的leader
2.2 傳送:producer傳送訊息到leader，並記錄到本地log
2.3 拉取：follower從leader拉取訊息後，記錄到本地log，並向leader發ack訊息
2.4 更新: leader收到所有isr所有的ack確認後，更新hw
3.1 fetch: consumer傳送fetchrequest到leader所在的broker
3.2 查詢：broker獲取訊息的start offset和size，查詢相應的訊息———根據offset查詢message
3.3 提交：consumer fetch到訊息後，提交偏移量
（1s內丟進了5w條資料，持續幾分鐘）
場景：某時間端使用者流量激增，導致伺服器網絡卡爆滿，磁碟卡死等
解決：首先對kafka限速，其次啟動重試機制（leader收到所有isr的ack訊息後，更新hw點,向client傳送ack訊息）
根本原因：根本原因是kafka已經消費了資料，但是沒有提交offset序列號
場景：1. consumer消費一條資料平均需要200ms時間，某時刻使用者流量激增
consumer取出一批資料進行消費，但是在session.timeout.ms時間之內沒有消費完成
導致consumer coordinator掛掉，kafka的自動提交失敗（offset不再更新），client重新分配分割槽
此時重新分配分割槽的consumer重複消費了之前傳送的資料
2. 消費邏輯 與 業務邏輯在乙個執行緒處理，可能會出現業務邏輯阻塞，導致session超時
解決：增加partition數量，提高consumer併發能力
適當延長session.timeout.ms的時間
對於單partition的consumer線 程，設定乙個執行緒池提高併發能力
減少每次從分割槽中獲取的 資料分片的大小
offset手動處理，業務邏輯成功後，再提交offset
通過資料庫 或 redis，保證資料唯一(唯一索引，先查詢是否存在) ——效率低
Linux UDP嚴重丟包問題的解決
測試系統在linux上的效能發現丟包率極為嚴重，發210000條資料，丟包達110000之巨，丟包率超過50 同等情形下windows上測試，僅丟幾條資料。形勢嚴峻，必須解決。考慮可能是因為協議棧buffer太低所致，於是先看看預設情況 sysctl a grep net.core 發現net.co...
Linux UDP嚴重丟包問題的解決
測試系統在linux上的效能發現丟包率極為嚴重，發210000條資料，丟包達110000之巨，丟包率超過50 同等情形下windows上測試，僅丟幾條資料。形勢嚴峻，必須解決。考慮可能是因為協議棧buffer太低所致，於是先看看預設情況 sysctl a grep net.core 發現net.co...
UDP丟包及無序的問題
最近在做乙個專案,在這之前,做了個驗證程式.發現客戶端連續發來1000個1024位元組的包,伺服器端出現了丟包現象.糾其原因,是服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了.有沒有成熟的解決方案來解決這個問題.我用過sleep 1 暫時解決這個問題,但是這不是根本解決辦法,如果資料量大...