2020-09-29

問題描述：線上業(yè)務出現推送延遲，啟動測試工具訂閱topic，能看到數據正常時間能對上（數據寫進去了），用kafka自帶的也能對上，
通過分析后發(fā)現工具記錄的日志在9點41分啟動-9點50分之間出現了秒級延遲（最多延遲16秒）。通過阿里云監(jiān)控發(fā)現有臺kafka磁盤IO是38M，檢查高效云盤磁盤IO吞吐量上限是140M/s，說明IO沒問題。
進一步發(fā)現網絡流出帶寬達到850M/s，和運維確認帶寬上限是800M/s，確認是出口帶寬引起讀取延遲。

用工具訂閱一個topic，打印數據和日志時間，發(fā)現一開始不延遲，但是慢慢出現數據內的時間戳（應用層加的）比日志時間小！！

1.運維規(guī)范：前段時間運維因成本原因對kafka規(guī)格降級，對應的帶寬也降低了，成本允許下服務器配置應該按峰值來預估，按需分配是值得商榷的，多少是需呢，拿最近半個月看就是需了嗎，沒有足夠的歷史數據參考，這個需對嗎？
2.開發(fā)規(guī)范：隨著業(yè)務發(fā)展，新增topic訂閱變多，存在增加一個小功能就訂閱一次topic的現象，這種情況需要杜絕。
3.部署規(guī)范：按業(yè)務分開部署，多個集群

解決：
1.關于topic訂閱，有些topic數據量比較大，應用功能能合的，合在一起，一次訂閱多次計算，以免流量暴漲。
2.生產寫數據時指定key，在多分區(qū)時，同一個key會落在相同的分區(qū)，這樣可以保證單個股票數據順序性。3個broker，設置3個分區(qū)，均衡資源并提高吞吐量。

擴展：
消息分配到分區(qū)有三種模式，分別是RandomPartitioner, RoundRobinPartitioner and HashPartitioner，sarama默認配置用HashPartitioner，同樣的key會落在相同的分區(qū)。

往kafka寫數據時指定KEY： msg := &sarama.ProducerMessage{Topic: "real-" + time.Now().Format("20060102"),Key: code,Value: sarama.StringEncoder(string(data)), } conn.KafkaProducer.Input() <- msg

總結

以上是生活随笔為你收集整理的kafka消费端慢慢延迟（网络带宽不足）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。