broker.id
区kafka集群中每台机器的标识
log.dirs
日志的存放目录，这个最好不要放到/tmp目录下，因为kafka的已被消费和未被消费的数据也被当成“日志”存放到了日志目录，；
log.retention.hours log.segment.bytes log.retention.check.interval.ms log.cleaner.enable=false
因为数据存放在日志目录中，所以在实际集群中会有大量的数据，这样会导致日志目录会不断增大，一些被消费过的数据和日志是可以被删掉的。第一个配置变量是定义多久删除清理一下日志目录，第二个配置变量是定义日志文件达到多大就清理一下，第三个是检查间隔，第四个个是是否开启清理，默认不开启的，所以实际集群中我觉得应该开启清理器，并根据集群的配置优化清理的时间间隔和文件饱和大小的值；
replication-factor
这个变量和Hadoop的dfs.replication类似，简单讲就是副本数，一般来说replication-factor的数量和broker的数量一样，这个变量讲深点涉及到kafka的fail/recover机制，它对效率有一定的影响，但是增加了可用性。
partition
一个topic的消息分为不同的部分或者说文件夹存放，这样做可以实现水平扩展，避免对单个文件I/O造成的瓶颈问题，实现读写的并行性
consumer group或者 group.id
这个必须记住一个规则：每个consumer实例都属于一个consumer group，每条消息只会被同一个consumer group的一个consumer实例消费，不同的consumer group可以同时消费同一条消息
consumer reblance
kafka的consumer group机制的优点是每个consumer不用跟大量的broker通信，减少通信开销，同时也降低了分配难度，另外，因为同一个partition数据是有序的，这种设计可以保证每个partition里的数据也可以被有序的消费；但是劣势则是无法让同一个consumer group的consumer均匀消费，如果某consumer group中consumer数量少于partition数量，则至少有一个consumer会消费多个partition的数据，如果consumer的数量与partition数量相同，则正好一个consumer消费一个partition的数据，而如果consumer的数量多于partition的数量时，会有部分consumer无法消费该topic下任何一条消息。于是有了reblance。