Kafka-broker主要配置

Kafka-broker配置

常规配置

broker.id

每个broker都需要有一个标识符，使用broker.id来表示。它的默认值是0，也可以被设置成其它任意整数。这个值在整个kafka集群里必须是唯一的。

port

默认配置中，kafka会监听9092端口。port可以改为任意可用端口。

需要注意的是，如果使用1024以下的端口，需要使用root权限启动kafka，不建议使用1024以下的端口。

zookeeper.connect

用于保存broker元数据的zookeeper地址

设置为localhost:2181,如果有多个，分号拼接。格式如下：hostname:port/path

hostname是zookeeper服务器的机器名或IP地址

port是zookeeper的客户端连接端口

/path是可选的zookeeper路径，作为kafka集群的chroot环境。如果不指定，默认使用根路径。如果指定的chroot路径不存在，broker会在启动的时候创建它。

log.dirs

kafka把所有消息都保存在磁盘上，存放这些日志片段的目录是通过log.dirs指定的。它是一组用逗号分隔的本地文件系统路径。如果指定了多个路径，那么broker会根据最少使用原则，把同一个分区的日志片段保存到同一个路径下。

要注意，broker会往拥有最少数据分区的路径新增分区，而不是往拥有最小磁盘空间的路径新增分区。

num.recovery.threads.per.data.dir

以下三种情况，kafka会使用可配置的线程池来处理日志片段

l 服务器正常启动，用于打开每个分区的日志片段

l 服务器崩溃后重启，用于检查和截短每个分区的日志片段

l 服务器正常关闭，用于关闭日志片段

默认情况下，每个日志目录只使用一个线程。这些线程只是在服务器启动和关闭时会用到，所以完全可以设置大量的线程来达到并行操作的目的。特别是对于包含大量分区的服务器来说，一旦发生崩溃，在进行恢复时使用并行操作可能会省下数小时的时间。

此配置的数字对应的是log.dirs指定的单个日志目录。比如：此值设置为8，log.dir指定了3个路径，那么总共会有24个线程。

auto.create.topics.enable

以下三种情况，kafka会自动创建主题

l 当一个生产者开始往主题写入消息时

l 当一个消费者开始从主题读取消息时

l 当任意一个客户端向主题发送元数据请求时

 

主题的默认配置

num.partitions

指定新创建的主题包含多少个分区。在设置此值时要综合考虑主题需要多大的吞吐量，从单个分区读取数据的最大吞吐量

如果消息是按照不同的键来写入分区的，那么为已有的主题新增分区就会很困难。

单个broker对分区个数是有限制的，因为分区越多，占用的内存越多，完成首领选举需要的时间也越长

分区数=主题吞吐量/消费者吞吐量。如果每秒要从主题上写入和读取1GB的数据，每个消费者每秒可以处理50MB，则至少需要20个分区。

把分区的大小限制在25GB以内可以得到比较理想的效果

log.retention.ms

决定数据可以被保留多久，默认使用log.retention.hours来配置时间，默认是168小时，一周。还有log.retention.minutes，kafka会使用值最小的那个时间。

根据时间保留数据是通过检查磁盘上日志片段文件的最后修改时间来实现的。一般来说，最后修改时间指的就是日志片段的关闭时间，也就是文件里最后一个消息的时间戳。

如果使用管理工具在服务器间移动分区，最后修改时间就不准确了。时间误差可能导致这些分区过多地保留数据

log.retention.types

通过保留的消息字节数来判断消息是否过期。该值作用在每个分区上。

如果有一个包含8个分区的主题，并且此值被设为1GB，那么主题最多可以保留8GB的数据。所以当主题分区个数增加时，整个主题可以保留的数据也随之增加

 

如果同时指定了log.retention.ms和log.retention.types，只要任意满足一个条件，消息就会被删除。

log.segment.bytes

当消息到达broker时，它们被追加到分区的当前日志片段上。当日志片段大小达到log.segment.bytes指定的上线（默认是1GB）时，当前日志片段就会被关闭，一个新的日志片段被打开。如果一个日志片段被关闭，就开始等待过期。

这个值设置的越小，就会越频繁的关闭和分配新文件，从而降低磁盘写入的整体效率。

如果一个主题每天只接收100MB消息，根据log.segment.bytes的默认配置1GB，则需要10天才能填满一个日志片段。因为在日志片段被关闭之前消息是不会过期的，所以如果log.retention.ms被设为168小时1周，那么日志片段最多需要17天才会过期。其中关闭日志片段需要10天，根据配置的过期时间，还需要再保留7天时间（要等到日志片段里的最后一个消息过期才能被删除）。

日志片段的大小会影响使用时间戳获取偏移量。在使用时间戳获取日志偏移量时，kafka会检查分区里最后修改时间大于指定时间戳的日志片段（已经被关闭）该日志片段的前一个文件的最后修改时间小于指定时间戳。然后，kafka返回该日志片段（也就是文件名）开头的偏移量。

对于使用时间戳获取偏移量的操作来说，日志片段越小，结果越精确。

log.segment.ms

可以通过此参数配置日志片段关闭的时间，它指定了多长时间之后日志片段会被关闭。

log.segment.bytes与log.segment.ms不存在互斥问题。日志片段会在大小或时间达到上限时被关闭，只要有一个值先满足了，就会关闭日志片段。

无默认值，默认只根据日志片段的大小来关闭日志片段

注意的问题：要着重考虑并行关闭多个日志片段对磁盘性能的影响。如果多个分区的日志片段永远不能达到大小的上限，就会发生这种情况，因为broker在启动之后就开始计算日志片段的过期时间，对于那些数据量小的分区来说，日志片段的关闭操作总是同时发生。

message.max.bytes

broker通过设置message.max.bytes参数来限制单个消息的大小，默认值是1000000，也就是1MB。

如果生产者尝试发送的消息超过此值，不仅消息不会被接收，还会收到broker返回的错误信息。

此值指的是压缩后的消息大小，消息的实际大小可以远大于这个值。

这个值对性能有显著的影响。值越大，那么负责处理网络连接和请求的线程就需要花越多的时间来处理这些请求。它还会增加磁盘写入块的大小，从而影响IO吞吐量

注意：消费者客户端设置的fetch.message.max.bytes必须与此值进行协调。如果fetch.message.max.bytes小于message.max.bytes，那么消费者就无法读取比较大的消息，导致出现消费者被阻塞的情况。