项目开发过程中遇到的一些问题：
问题1：环境中配置的replica.fetch.max.bytes该值偏大，导致有节点下线后同步数据会出现网卡塞满的情况，建议该值在百兆网下配置10M，千兆网20M左右。
问题2：kafka不消费数据。后来发现是超时时间设置的的太短，消费还未处理完就已经被kafka认为超时，导致消费失败，offset不提交，所以一直消费那一批数据。修改超时时间即可。
问题3：自己管理offset的时候，在发生ConsumerRebalance时需要清除保存的信息，不然在下次切换时可能存在offset大量回退，原因如下：
如0,1共两个partition，线程1消费0，线程2消费1,在发生切换时，两个线程都没有清除原始的记录，会出现线程1保存0、1,线程2也保存0、1，而实际消费中线程1中只会拉去1，线程2只会拉取0，而不会更新其他的partition的offset，导致下次再发生切换时没有更新的partition被提交到kafka中就会出现大量回退。
补充： Kafka Consumer的Reblance机制介绍
Reblance本质上是一种协议，规定了一个Consumer Group下的所有的Consumer如何达成一致来分配订阅Topic的每个Partition。比如某个group下有5个consumer，它订阅了一个具有10个分区的topic。正常情况下，Kafka平均会为每个consumer分配2个分区。这个分配的过程就叫rebalance。
Rebalance的触发条件：
1.有新的消费者加入Consumer Group
2.有消费者下线，可能由于长时间未向GroupCoordinator(协调者)发送心跳，GroupCoordinator会认为其已下线
3.有消费者主动退出Consumer Group
4.订阅的topic分区出现变化
5.调用unsubscribe()取消对某Topic的订阅
即Consumer或者Topic自身发生变化时，会触发Rebalance。
GroupCoordinator(协调者)：
GroupCoordinator是协调消费者组完成消费者Rebalance的重要组件，每一个broker都会启动一个GroupCoodinator，Kafka 按照消费者组的名称将其分配给对应的GroupCoodinator进行管理；每一个GroupCoodinator只负责管理一部分消费者组，而非集群中全部的消费者组。
分区的分配策略主要有三种：
1.RangePartitionAssignor：
针对每一个topic：
n = 分区数/消费者数量
m = 分区数%消费者数量
前m个消费者每个分配n+1个分区，后面的 （消费者数量-m）个消费者每个分配n个分区
2.RoundRobinAssignor：
将所有的Topic和Partition按照字典顺序排序，然后对每个Consumer进行轮询分配
3.自定义分配策略：实现AbstractPartitionAssignor类的assign()方法
参考：
www.cnblogs.com/huxi2b/p/6223228.html(Kafka reblance流程分析)