经验：
- 关闭kafka自动创建topic（副本数，分区数）:auto.create.topics.enable=true
- 副本数默认是1（default.replication.factor=3）
- 分区数默认是5（num.partitions=50）:不是越大越好，小等于集群总核数
- 启用删除topic：delete.topic.enable=true
- 日志保留天数：log.retention.hours=168（默认是7天）
一、kafka日志量过大的问题
解决方法：
1、方法一：更改~/kafka_2.11-0.9.0.0/config/log4j.properties
自身日志是按照小时去备份的，而且没有自动清除的功能，所以自身日志一直没有清掉，就可能会影响到对数据量的预估和判断。这时候我们只想保留最近n天的日志。log4j并没有配置这样的功能，在不改动源码的情况下，有两种办法达到目的。
log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=[%d] %p %m (%c)%n
log4j.appender.kafkaAppender=org.apache.log4j.RollingFileAppender
log4j.appender.kafkaAppender.append=true
log4j.appender.kafkaAppender.maxBackupIndex=2
log4j.appender.kafkaAppender.maxFileSize=5MB
log4j.appender.kafkaAppender.File=${kafka.logs.dir}/server.log
log4j.appender.kafkaAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.kafkaAppender.layout.ConversionPattern=[%d] %p %m (%c)%n
二、kafka分区（partition）策略
1、kafka选择分区的原则
选择分区的原则：
1.主题需要多大的吞吐量，是希望每秒写入100kb,还是1GB
2.从单个分区读取数据的最大吞吐量，数据写入数据库的速度不会超过每秒50M,所以从一个分区读数据的速度也不要超过50M
3.可以估算生产者向单个分区写入数据的吞吐量，生产者的速度一般比消费者快，最高为生产者多估算一些量。
4.每个broker包含的分区个数，可用磁盘空间和网络带宽
5.若消息按照不同的键来写入分区，那么为已有的主题新增分区就很困难
6.单个broker对分区个数是有限制，因为分区越多，占用的内存越多，完成首领的选举需要更长的时间。
使用主题吞吐量除以消费者吞吐量算出分区个数。也就是每秒从主题上写入和读取1GB的数据，并且每个消费者每秒钟可以处理50MB数据。那么至少需要20个分区，这样20个消费者同时读取这些分区，从而达到每秒1GB的数据。
如果不知道以上信息，最好把分区大小限制再25GB以内可以得到比较理想得效果。
2、如何决定kafka集群中topic的分区的数量
如何决定kafka集群中topic,partition的数量，这是许多kafka用户经常遇到的问题
1、分区多吞吐量更高
一个话题topic的各个分区partiton之间是并行的。在producer和broker方面，写不同的分区是完全并行的。因此一些昂贵的操作比如压缩，可以获得更多的资源，因为有多个进程。在consumer方面，一个分区的数据可以由一个consumer线程在拉去数据。分区多，并行的consumer（同一个消费组）也可以多。因此通常，分区越多吞吐量越高。
基于吞吐量可以获得一个粗略的计算公式。先测量得到在只有一个分区的情况下，Producer的吞吐量(P)和Consumer的吞吐量(C)。那如果总的目标吞吐量是T的话，max(T/P,T/C)就是需要的最小分区数。在单分区的情况下，Producer的吞吐量可以通过一些配置参数，比如bath的大小、副本的数量、压缩格式、ack类型来测得。而Consumer的吞吐量通常取决于应用程序处理每一天消息逻辑。这些都是需要切合实际测量。
随着时间推移数据量的增长可能会需要增加分区。有一点需要注意的是，Producer者发布消息通过key取哈希后映射分发到一个指定的分区，当分区数发生变化后，会带来key和分区映射关系发生变化。可能某些应用程序依赖key和分区映射关系，映射关系变化了，程序就需要做相应的调整。为了避免这种key和分区关系带来的应用程序修改。所以在分区的时候尽量提前考虑，未来一年或两年的对分区数据量的要求。
除了吞吐量，还有一些其他的因素，在定分区的数目时是值得考虑的。在某些情况下，太多的分区也可能会产生负面影响。
2、分区多需要的打开的文件句柄也多
每个分区都映射到broker上的一个目录，每个log片段都会有两个文件（一个是索引文件，另一个是实际的数据文件）。分区越多所需要的文件句柄也就越多，可以通过配置操作系统的参数增加打开文件句柄数。
3、分区多增加了不可用风险
kafka支持主备复制，具备更高的可用性和持久性。一个分区（partition）可以有多个副本，这些副本保存在不同的broker上。每个分区的副本中都会有一个作为Leader。当一个broker失败时，Leader在这台broker上的分区都会变得不可用，kafka会自动移除Leader，再其他副本中选一个作为新的Leader。Producer和Consumer都只会与Leader相连。
一般情况下，当一个broker被正常关机时，controller主动地将Leader从正在关机的broker上移除。移动一个Leader只需要几毫秒。然当broker出现异常导致关机时，不可用会与分区数成正比。假设一个boker上有2000个分区，每个分区有2个副本，那这样一个boker大约有1000个Leader，当boker异常宕机，会同时有1000个分区变得不可用。假设恢复一个分区需要5ms，1000个分区就要5s。
分区越多，在broker异常宕机的情况，恢复所需时间会越长，不可用风险会增加。
4、分区多会增加点到点的延迟
这个延迟需要体现在两个boker间主备数据同步。在默认情况下，两个boker只有一个线程负责数据的复制。
根据经验，每个boker上的分区限制在100*b*r内（b指集群内boker的数量，r指副本数量）。
5、分区多会增加客户端的内存消耗
8.2后有个比较好的特色，新的Producer可以允许用户设置一个缓冲区，缓存一定量的数据。当缓冲区数据到达设定量或者到时间，数据会从缓存区删除发往broker。如果分区很多，每个分区都缓存一定量的数据量在缓冲区，很可能会占用大量的内存，甚至超过系统内存。
Consumer也存在同样的问题，会从每个分区拉一批数据回来，分区越多，所需内存也就越大。
根据经验，应该给每个分区分配至少几十KB的内存。
在通常情况下，增加分区可以提供kafka集群的吞吐量。然而，也应该意识到集群的总分区数或是单台服务器上的分区数过多，会增加不可用及延迟的风险。
三、kafka的偏移量
earliest: automatically reset the offset to the earliest offset,翻译过来就是自动将偏移量置为最早的
latest:automatically reset the offset to the latest offset 自动将偏移量设置为最新的
可能大部分朋友都觉得在任何情况下把这两个值设置为earliest或者latest ,消费者就可以从最早或者最新的offset开始消费,但在实际上测试的时候发现并不是那么回事,因为他们生效都有一个前提条件,那就是对于同一个groupid的消费者,如果这个topic某个分区有已经提交的offset,那么无论是把auto.offset.reset=earliest还是latest,都将失效,消费者会从已经提交的offset开始消费.
earliest
当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费
latest
当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据
如果想测试的话,可以把kafka的enable.offset.commit设置为false,让kafka的自动提交功能关闭,这时候对于某个topic就没有已经提交的offset了,对于同一个groupid来说,不管是earliest还是latest,consumer都可以从最早或者最新的offset开始消费
四、其他问题
五、kafka常用命令
https://cloud.tencent.com/developer/article/1350788
