kafka broker配置

kafka现在是所有队列组件里最常用的，虽然跟Rabbitmq这些相比还缺乏一些特性，但是它实在是成长的太快了，而且支持集群化，这个是最赞的，同时由于使用0拷贝，日志追加，所以它的磁盘效率非常高。

但是kafka的运维难度前期并不大，但是在后期主要的难点是在扩容，缩容阶段。主要是因为磁盘IO，网络IO的原因。导致了很多瓶颈点产生。

本文是读了「kafka权威指南」第二章的一个摘要总结。

broker整体配置

log.dirs

kafka是把所有消息都写入到磁盘，这个参数可以指定多个目录进行消息写入。而写入的原则是最少使用原则。
但是我们在实际使用中，不建议写多个，宁愿使用raid，LVM条带方式来扩展单目录的写入速度。

num.recovery.threads.per.data.dir

这个参数看名字是崩溃后恢复时候多少线程来处理每个消息目录。
但是在书里说明共有3种情况会使用这个

• 服务器正常启动，用户打开每个分区的日志片段
• 服务器崩溃重启，用于检查和截短每个分区的日志片段。
• 服务器正常关闭，用于关闭日志片段。
  如果我们设置为8，那就是每个消息目录会产生8个线程进行处理。

auto.create.topics.enable

如果设置为true，那会在下列3种情况下自动创建topic

• 当一个生产者开始往topic写入消息时
• 当一个消费者开始从topic读取消息时
• 当任意一个客户端向主题发送元数据请求时
  这个看各自情况吧，一般大型互联网公司应该都会设置为false，因为这样可以手动创建topic的时候指定很多topic的参数。特别是你的kafka里存放的topic类型区别很大的时候。

topic配置

0.8版本以及之前的版本允许topic的配置覆盖服务器的默认配置。而现在的版本需要使用管理工具来设置这些参数。

num.partitions

kafka topic的partition数量只能增加，不能减少。
一般来说partition数量肯定要大于broker数量。
至于如何确定分区的数量，作者列出了如下几条：

• topic需要达到多少吞吐量？ 每秒的写入量是多少。
• 从单个分区读取数据的最大吞吐量是多少？这个大小肯定是小于整体topic的吞吐量的。
• 估算生产者向单个分区写入数据的吞吐量，不过生产者的速度一般比消费者快得多，所以要给生产者多估算一些吞吐量。
• 每个broker包含的分区个数、可用的磁盘空间和网络带宽。
• 如果消息是按照不同的key来写入分区的，那么为已有的topic新增分区就会很困难。
• 单个broker对分区个数是有限制的，因为分区越多，占用的内存越多，完成leader选举需要的时间也越长。

根据经验来说，把单个分区的大小限制在25GB以内可以得到比较理想的效果。

log.retention.ms

这里其实有3个参数都可以，一般我们使用log.retention.hours来设置，毕竟看着好认识。还有就是log.retention.minutes
当我们指定了多个参数，那就以最小的为准。但是我们千万不要这样干，对于后面排查起来就麻烦了。

log.retention.bytes

这个就是表示单个分区的保留大小。

上面这两个参数只要任意一个条件得到满足，消息就会被删除。

log.segment.bytes

这个是设置消息片段的大小，默认是1GB。只有当日志片段达到了指定的上线，当前日志片段就会被关闭，一个新的才会打开。
所以当你每个分区日志量小的情况下，一定要设置下这个参数。
比如一个分区每天只有100M的消息，log.segment.bytes是默认设置，那么需要10天才能写满一个日志片段。而log.retention.ms设置为604800000（也就是一周），那么这个日志片段最多需要17天才会过期。
因为要等到日志片段里的最后一个消息过期才能被删除。

log.segment.ms

这个默认是没有设置的。
主要是基于时间来设置的话，一个topic的多个分区在一个服务器上会同时达到话，这样导致磁盘性能下降。

message.max.bytes

限制单个消息的大小。默认是1000000，也就是1MB。这个大小是压缩后的消息大小，解压开来（broker的CPU主要是干这个了）会远远超过这个大小。
这个值一定要跟客户端协同好。