應用kafka的總結

consumer offset commit

使用kafka的python api時遇到了offset回滾的問題，由於最初使用了autocommit參數，發現有時會重複取記錄，發現autocommit是批量提交，而且有offset回滾的問題，具體緣由未發現，解決方法是手動調用commit函數提交，通過測試手動調用沒有出現offset回滾的問題。

partition

一開始爲了簡單隻使用了一個分區，consumer都從一個leader取數據，請求壓力都在一臺機器。使用不一樣分區策略能夠分散topic的leader，還能夠靈活處理不一樣數據。

fetch msg

MaxWaitTime 請求最大等待時間，MinBytes 請求消息的最小字節數，經過這2個參數能夠調整你獲取數據時的等待策略，最簡單的作法就是不等待，沒數據直接返回。

zookeeper

對於zookeeper不太瞭解，所以忽略了dataDir和dataLogDir這2個目錄的配置對系統形成的影響。因爲硬盤限制，把kafka和zookeeper的日誌目錄放在了同一個磁盤，並且磁盤的性能不是很好，形成了kafka寫數據效率低下，每次寫數據只有幾百k。zookeeper網站上對這2個配置有Notes說不要把他們放在繁忙的磁盤設備上，會影響其餘程序寫磁盤的性能，最好這2個目錄都分開存放不一樣設備。簡單看了一下，dataDir下存的是snapshot文件，dataLogDir存的是log文件，應該是zookeeper把內存數據持久化到這2種文件中了，並且持久化操做很頻繁且寫的數據不多，會影響kafka寫日誌。

iostat -d -x

這是關於磁盤性能監控的。在排查磁盤io高的問題時用到了iostat -d -x 命令，因爲對磁盤不是很瞭解，在排查時主要關注w/s、wkB/s、rkB/s，對於扇區沒怎麼關注，rsec/s wsec/s avgrq-sz這幾個參數反應磁盤操做扇區的狀況，當磁盤利用率高且iowait高，而平均扇區低也就意味着磁盤把大量時間用於磁盤尋道，你可能須要考慮是否是有大量隨機寫磁盤的操做。

end

以上是對在使用kafka時遇到的問題的一些總結。