Kafka配置参数详解
Posted yjl33
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Kafka配置参数详解相关的知识，希望对你有一定的参考价值。
基本配置如下：
-broker.id
-log.dirs
-zookeeper.connect
Topic-level配置以及其默认值将在下面讨论。
| Property | Default | Description |
| broker.id | 每个broker都可以用一个唯一的非负整数id进行标识；这个id可以作为broker的“名字”，并且它的存在使得broker无须混淆consumers就可以迁移到不同的host/port上。你可以选择任意你喜欢的数字作为id，只要id是唯一的即可。 | |
| log.dirs | /tmp/kafka-logs | kafka存放数据的路径。这个路径并不是唯一的，可以是多个，路径之间只需要使用逗号分隔即可；每当创建新partition时，都会选择在包含最少partitions的路径下进行。 |
| port | 6667 | server接受客户端连接的端口 |
| zookeeper.connect | null | ZooKeeper连接字符串的格式为：hostname:port，此处hostname和port分别是ZooKeeper集群中某个节点的host和port；为了当某个host宕掉之后你能通过其他ZooKeeper节点进行连接，你可以按照一下方式制定多个hosts： |
| message.max.bytes | 1000000 | server可以接收的消息最大尺寸。重要的是，consumer和producer有关这个属性的设置必须同步，否则producer发布的消息对consumer来说太大。 |
| num.network.threads | 3 | server用来处理网络请求的网络线程数目；一般你不需要更改这个属性。 |
| num.io.threads | 8 | server用来处理请求的I/O线程的数目；这个线程数目至少要等于硬盘的个数。 |
| background.threads | 4 | 用于后台处理的线程数目，例如文件删除；你不需要更改这个属性。 |
| queued.max.requests | 500 | 在网络线程停止读取新请求之前，可以排队等待I/O线程处理的最大请求个数。 |
| host.name | null | broker的hostname；如果hostname已经设置的话，broker将只会绑定到这个地址上；如果没有设置，它将绑定到所有接口，并发布一份到ZK |
| advertised.host.name | null | 如果设置，则就作为broker 的hostname发往producer、consumers以及其他brokers |
| advertised.port | null | 此端口将给与producers、consumers、以及其他brokers，它会在建立连接时用到； 它仅在实际端口和server需要绑定的端口不一样时才需要设置。 |
| socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF 缓存大小，server进行socket 连接所用 |
| socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF缓存大小，server进行socket连接时所用 |
| socket.request.max.bytes | 100 * 1024 * 1024 | server允许的最大请求尺寸； 这将避免server溢出，它应该小于Java heap size |
| num.partitions | 1 | 如果创建topic时没有给出划分partitions个数，这个数字将是topic下partitions数目的默认数值。 |
| log.segment.bytes | 1014*1024*1024 | topic partition的日志存放在某个目录下诸多文件中，这些文件将partition的日志切分成一段一段的；这个属性就是每个文件的最大尺寸；当尺寸达到这个数值时，就会创建新文件。此设置可以由每个topic基础设置时进行覆盖。 |
| log.roll.hours | 24 * 7 | 即使文件没有到达log.segment.bytes，只要文件创建时间到达此属性，就会创建新文件。这个设置也可以有topic层面的设置进行覆盖； |
| log.cleanup.policy | delete | |
| log.retention.minutes和log.retention.hours | 7 days | 每个日志文件删除之前保存的时间。默认数据保存时间对所有topic都一样。 |
| log.retention.bytes | -1 | 每个topic下每个partition保存数据的总量；注意，这是每个partitions的上限，因此这个数值乘以partitions的个数就是每个topic保存的数据总量。同时注意：如果log.retention.hours和log.retention.bytes都设置了，则超过了任何一个限制都会造成删除一个段文件。 |
| log.retention.check.interval.ms | 5 minutes | 检查日志分段文件的间隔时间，以确定是否文件属性是否到达删除要求。 |
| log.cleaner.enable | false | 当这个属性设置为false时，一旦日志的保存时间或者大小达到上限时，就会被删除；如果设置为true，则当保存属性达到上限时，就会进行log compaction。 |
| log.cleaner.threads | 1 | 进行日志压缩的线程数 |
| log.cleaner.io.max.bytes.per.second | None | 进行log compaction时，log cleaner可以拥有的最大I/O数目。这项设置限制了cleaner，以避免干扰活动的请求服务。 |
| log.cleaner.io.buffer.size | 500*1024*1024 | log cleaner清除过程中针对日志进行索引化以及精简化所用到的缓存大小。最好设置大点，以提供充足的内存。 |
| log.cleaner.io.buffer.load.factor | 512*1024 | 进行log cleaning时所需要的I/O chunk尺寸。你不需要更改这项设置。 |
| log.cleaner.io.buffer.load.factor | 0.9 | log cleaning中所使用的hash表的负载因子；你不需要更改这个选项。 |
| log.cleaner.backoff.ms | 15000 | 进行日志是否清理检查的时间间隔 |
| log.cleaner.min.cleanable.ratio | 0.5 | 这项配置控制log compactor试图清理日志的频率（假定log compaction是打开的）。默认避免清理压缩超过50%的日志。这个比率绑定了备份日志所消耗的最大空间（50%的日志备份时压缩率为50%）。更高的比率则意味着浪费消耗更少，也就可以更有效的清理更多的空间。这项设置在每个topic设置中可以覆盖。 |
| log.cleaner.delete.retention.ms | 1day | 保存时间；保存压缩日志的最长时间；也是客户端消费消息的最长时间，荣log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据；会被topic创建时的指定时间覆盖。 |
| log.index.size.max.bytes | 10*1024*1024 | 每个log segment的最大尺寸。注意，如果log尺寸达到这个数值，即使尺寸没有超过log.segment.bytes限制，也需要产生新的log segment。 |
| log.index.interval.bytes | 4096 | 当执行一次fetch后，需要一定的空间扫描最近的offset，设置的越大越好，一般使用默认值就可以 |
| log.flush.interval.messages | Long.MaxValue | log文件“sync”到磁盘之前累积的消息条数。因为磁盘IO操作是一个慢操作，但又是一个“数据可靠性”的必要手段，所以检查是否需要固化到硬盘的时间间隔。需要在“数据可靠性”与“性能”之间做必要的权衡，如果此值过大，将会导致每次“发sync”的时间过长（IO阻塞），如果此值过小，将会导致“fsync”的时间较长（IO阻塞），如果此值过小，将会导致”发sync“的次数较多，这也就意味着整体的client请求有一定的延迟，物理server故障，将会导致没有fsync的消息丢失。 |
| log.flush.scheduler.interval.ms | Long.MaxValue | 检查是否需要fsync的时间间隔 |
| log.flush.interval.ms | Long.MaxValue | 仅仅通过interval来控制消息的磁盘写入时机，是不足的，这个数用来控制”fsync“的时间间隔，如果消息量始终没有达到固化到磁盘的消息数，但是离上次磁盘同步的时间间隔达到阈值，也将触发磁盘同步。 |
| log.delete.delay.ms | 60000 | 文件在索引中清除后的保留时间，一般不需要修改 |
| auto.create.topics.enable | true | 是否允许自动创建topic。如果是真的，则produce或者fetch 不存在的topic时，会自动创建这个topic。否则需要使用命令行创建topic |
| controller.socket.timeout.ms | 30000 | partition管理控制器进行备份时，socket的超时时间。 |
| controller.message.queue.size | Int.MaxValue | controller-to-broker-channles的buffer 尺寸 |
| default.replication.factor | 1 | 默认备份份数，仅指自动创建的topics |
| replica.lag.time.max.ms | 10000 | 如果一个follower在这个时间内没有发送fetch请求，leader将从ISR重移除这个follower，并认为这个follower已经挂了 |
| replica.lag.max.messages | 4000 | 如果一个replica没有备份的条数超过这个数值，则leader将移除这个follower，并认为这个follower已经挂了 |
| replica.socket.timeout.ms | 30*1000 | leader 备份数据时的socket网络请求的超时时间 |
| replica.socket.receive.buffer.bytes | 64*1024 | 备份时向leader发送网络请求时的socket receive buffer |
| replica.fetch.max.bytes | 1024*1024 | 备份时每次fetch的最大值 |
| replica.fetch.min.bytes | 500 | leader发出备份请求时，数据到达leader的最长等待时间 |
| replica.fetch.min.bytes | 1 | 备份时每次fetch之后回应的最小尺寸 |
| num.replica.fetchers | 1 | 从leader备份数据的线程数 |
| replica.high.watermark.checkpoint.interval.ms | 5000 | 每个replica检查是否将最高水位进行固化的频率 |
| fetch.purgatory.purge.interval.requests | 1000 | fetch 请求清除时的清除间隔 |
| producer.purgatory.purge.interval.requests | 1000 | producer请求清除时的清除间隔 |
| zookeeper.session.timeout.ms | 6000 | zookeeper会话超时时间。 |
| zookeeper.connection.timeout.ms | 6000 | 客户端等待和zookeeper建立连接的最大时间 |
| zookeeper.sync.time.ms | 2000 | zk follower落后于zk leader的最长时间 |
| controlled.shutdown.enable | true | 是否能够控制broker的关闭。如果能够，broker将可以移动所有leaders到其他的broker上，在关闭之前。这减少了不可用性在关机过程中。 |
| controlled.shutdown.max.retries | 3 | 在执行不彻底的关机之前，可以成功执行关机的命令数。 |
| controlled.shutdown.retry.backoff.ms | 5000 | 在关机之间的backoff时间 |
| auto.leader.rebalance.enable | true | 如果这是true，控制者将会自动平衡brokers对于partitions的leadership |
| leader.imbalance.per.broker.percentage | 10 | 每个broker所允许的leader最大不平衡比率 |
| leader.imbalance.check.interval.seconds | 300 | 检查leader不平衡的频率 |
| offset.metadata.max.bytes | 4096 | 允许客户端保存他们offsets的最大个数 |
| max.connections.per.ip | Int.MaxValue | 每个ip地址上每个broker可以被连接的最大数目 |
| max.connections.per.ip.overrides | 每个ip或者hostname默认的连接的最大覆盖 | |
| connections.max.idle.ms | 600000 | 空连接的超时限制 |
| log.roll.jitter.ms,hours | 0 | 从logRollTimeMillis抽离的jitter最大数目 |
| num.recovery.threads.per.data.dir | 1 | 每个数据目录用来日志恢复的线程数目 |
| unclean.leader.election.enable | true | 指明了是否能够使不在ISR中replicas设置用来作为leader |
| delete.topic.enable | false | 能够删除topic |
| offsets.topic.num.partitions | 50 | The number of partitions for the offset commit topic. Since changing this after deployment is currently unsupported, we recommend using a higher setting for production (e.g., 100-200). |
| offsets.topic.retention.minutes | 1440 | 存在时间超过这个时间限制的offsets都将被标记为待删除 |
| offsets.retention.check.interval.ms | 600000 | offset管理器检查陈旧offsets的频率 |
| offsets.topic.replication.factor | 3 | topic的offset的备份份数。建议设置更高的数字保证更高的可用性 |
| offset.topic.segment.bytes | 104857600 | offsets topic的segment尺寸。 |
| offsets.load.buffer.size | 5242880 | 以上是关于Kafka配置参数详解的主要内容，如果未能解决你的问题，请参考以下文章 |