應用kafka的總結

標籤：io   os   使用   ar   檔案   資料   art   sp   問題   

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時遇到的問題的一些總結。

應用kafka的總結