1）  重复消费问题。

问题描述 
采用kafka读取消息进行处理时，consumer会重复读取afka队列中的数据。

问题原因 
kafka的consumer消费数据时首先会从broker里读取一批消息数据进行处理，处理完成后再提交offset。而我们项目中的consumer消费能力比较低，导致取出的一批数据在session.timeout.ms时间内没有处理完成，自动提交offset失败，然后kafka会重新分配partition给消费者，消费者又重新消费之前的一批数据，又出现了消费超时，所以会造成死循环，一直消费相同的数据。

解决方案 
项目中使用的是spring-kafka，所以把kafka消费者的配置enable.auto.commit设为false，禁止kafka自动提交offset，从而使用spring-kafka提供的offset提交策略。spring-kafka中的offset提交策略可以保证一批消息数据没有完成消费的情况下，也能提交offset，从而避免了提交失败而导致永远重复消费的问题。

2） Server.properties配置问题

borker，partition，replica 的配置之间的关系。

约束关系：Topic Partition Replicas Size <= Kafka Brokers Size。

创建Topic时直接指定Topic Partition Replica与Kafka Broker之间的存储映射关系

例如：kafka_2.10-0.8.2.1/bin/kafka-topics.sh --zookeeper ZooKeeperHost:ZooKeeperPort --create --topic TopicName --replica-assignment id0:id1:id2,id3:id4:id5,id6:id7:id8

其中，“id0:id1:id2,id3:id4:id5,id6:id7:id8”表示Topic TopicName一共有3个Partition（以“,”分隔），每个Partition均有3个Replica（以“:”分隔）

我们的策略：replicas >=2 ,确保有一个副本；partion=cpu cores，最大化利用多核并发。Brokers>=3 。根据gps数据量，系统吞吐量具体设计。

3） Zookeeper 问题。

Kafka集群强烈依赖zookeeper 来做集群的配置，状态，failover等机制。如果zookeeper集群出行问题，kafka集群也会不可用。所以要确保zookeeper集群的健康健壮。商用系统最少是3个zookeeper 集群节点，条件允许，应该是5个节点。

4） 消息保存时间。

无论消息是否被消费，kafka 都会保留所有消息。有两种策略可以删除旧数据：

1. 基于时间：log.retention.hours=168

2. 基于大小：log.retention.bytes=1073741824

需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。我们选择基于文件大小的配置即可。

5） 机器内存配置，文件配置

内存不能少于1G，最好2G。/bin/zookeeper-server-start.sh 中的内存配置。

6） consumer group问题

high-level consumer API 提供了 consumer group 的语义，一个消息只能被 group 内的一个 consumer 所消费，且 consumer 消费消息时不关注 offset，最后一个 offset 由 zookeeper 保存。

使用 high-level consumer API 可以是多线程的应用，应当注意：

1. 如果消费线程大于 patition 数量，则有些线程将收不到消息

2. 如果 patition 数量大于线程数，则有些线程多收到多个 patition 的消息

3. 如果一个线程消费多个 patition，则无法保证你收到的消息的顺序，而一个 patition 内的消息是有序的

例如：我们根据车牌号设计消息路由到指定的partion，多线程消费时，在提升gps数据解析性能的情况下，每辆车的gps时序也不会错乱。每个消费线程消费一个partion的数据，多线程则可以并行处理多个partion的gps数据。