应用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时遇到的问题的一些总结。