Kafka学习整理三(borker(0.9.0及0.10.0)配置)

Kafka日志本身是由多个日志段组成(log segment)。一个日志是一个FileMessageSet，它包含了日志数据以及OffsetIndex对象，该对象使用位移来读取日志数据 
* borker配置就是指配置server.properties文件 *

最小配置

通常情况下需要在减压缩kafka后，修改config/server.properties 配置文件中的以下两项

log.dirs = kafka-logszookeeper.connect = localhost:9092listeners = PLAINTEXT://ip:9092
1
2
3

1. log.dirs 指的是kafka的log Data保存的目录，默认为Null。如果不指定log Data会保存到log.dir设置的目录中，log.dir默认为/tmp/kafka-logs。需要保证启动KafKaServer的用户对log.dirs或log.dir设置的目录具有读与写的权限。

2. zookeeper.connect 指的是zookeeper集群的地址，可以是多个，多个之间用逗号分割hostname1:port1,hostname2:port2,hostname3:port3

3. listeners 监听列表(以逗号分隔 不同的协议(如plaintext,trace,ssl、不同的IP和端口))

kafka提供的borker配置

# Replication configurationsnum.replica.fetchers=4replica.fetch.max.bytes=1048576replica.fetch.wait.max.ms=500replica.high.watermark.checkpoint.interval.ms=5000replica.socket.timeout.ms=30000replica.socket.receive.buffer.bytes=65536replica.lag.time.max.ms=10000controller.socket.timeout.ms=30000controller.message.queue.size=10# Log configurationnum.partitions=8message.max.bytes=1000000auto.create.topics.enable=truelog.index.interval.bytes=4096log.index.size.max.bytes=10485760log.retention.hours=168log.flush.interval.ms=10000log.flush.interval.messages=20000log.flush.scheduler.interval.ms=2000log.roll.hours=168log.retention.check.interval.ms=300000log.segment.bytes=1073741824# ZK configurationzookeeper.connection.timeout.ms=6000zookeeper.sync.time.ms=2000# Socket server configurationnum.io.threads=8num.network.threads=8socket.request.max.bytes=104857600socket.receive.buffer.bytes=1048576socket.send.buffer.bytes=1048576queued.max.requests=16fetch.purgatory.purge.interval.requests=100producer.purgatory.purge.interval.requests=100
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

配置详细说明

名称说明类型默认值有效值重要性zookeeper.connectzookeeper集群的地址，可以是多个，多个之间用逗号分割stringlocalhost:2181ip1:port1,ip2:port2高zookeeper.connection.timeout.ms客户端在建立通zookeeper连接中的最大等待时间intnull6000高zookeeper.session.timeout.msZooKeeper的session的超时时间，如果在这段时间内没有收到ZK的心跳，则会被认为该Kafka server挂掉了。如果把这个值设置得过低可能被误认为挂掉，如果设置得过高，如果真的挂了，则需要很长时间才能被server得知int6000 高zookeeper.sync.time.ms一个ZK follower能落后leader的时间int2000 高listeners监听列表(以逗号分隔 不同的协议(如plaintext,trace,ssl、不同的IP和端口)),hostname如果设置为0.0.0.0则绑定所有的网卡地址；如果hostname为空则绑定默认的网卡。如果没有配置则默认为java.net.InetAddress.getCanonicalHostName()stringnull如：PLAINTEXT://myhost:9092,TRACE://:9091 或 PLAINTEXT://0.0.0.0:9092,高host.name。如果设置了它，会仅绑定这个地址。如果没有设置，则会绑定所有的网络接口，并提交一个给ZK。不推荐使用 只有当listeners没有设置时才有必要使用。string“’如：”localhost”高portserver用来接受client连接的端口。不推荐使用,使用listeners配置项代替；只有在listeners没有配置时才使用。int9092 高advertised.host.name会将hostname通知给生产者和消费者，在多网卡时需要设置该值为另一个ip地址。如果没有设置该值，则返回 配置项host.name设置的值，如果host.name没有设置则返回java.net.InetAddress.getCanonicalHostName()不推荐使用 只有当advertised.listeners或listeners没有设置时才有必要使用。stringnull 高advertised.listeners设置不同于listeners配置的监听列表即不同于listeners设置的网卡地址及端口；如果没有配置，会使用listeners的值stringnull 高advertised.port分发这个端口给所有的producer，consumer和其他broker来建立连接。如果此端口跟server绑定的端口不同，则才有必要设置。不推荐使用 只有当advertised.listeners或listeners没有设置时才有必要使用。intnull 高auto.create.topics.enable是否允许自动创建topic。如果设为true，那么produce，consume或者fetch metadata一个不存在的topic时，就会自动创建一个默认replication factor和partition number的topic。booleantrue 高background.threads一些后台任务处理的线程数，例如过期消息文件的删除等，一般情况下不需要去做修改int10 高broker.id每一个broker在集群中的唯一表示，要求是正数。当该服务器的IP地址发生改变时，broker.id没有变化，则不会影响consumers的消息情况。int-1 高compression.type指定topic的压缩类型。除了支持’gzip’, ‘snappy’, ‘lz4’外，还支持”uncompressed(不压缩)”以及producer(由producer来指定)stringproducer 高delete.topic.enable是否启动删除topic。如果设置为false,你在删除topic的时候无法删除，但是会打上一个你将删除该topic的标记，等到你修改这一属性的值为true后重新启动Kafka集群的时候，集群自动将那些标记删除的topic删除掉，对应的log.dirs目录下的topic目录和数据也会被删除。而将这一属性设置为true之后，你就能成功删除你想要删除的topic了booleanfalse 高auto.leader.rebalance.enable一个后台线程会周期性的自动尝试，为所有的broker的每个partition平衡leadership，使kafka的leader均衡。booleantrue 高leader.imbalance.check.interval.seconds检查leader是否均衡的时间间隔(秒)long300 高leader.imbalance.per.broker.percentage每个broker允许的不平衡的leader的百分比。如果每个broker超过了这个百分比，复制控制器会重新平衡leadership。int10 高log.flush.interval.messages数据flush(sync)到硬盘前之前累积的消息条数，因为磁盘IO操作是一个慢操作,但又是一个”数据可靠性”的必要手段,所以此参数的设置,需要在”数据可靠性”与”性能”之间做必要的权衡.如果此值过大,将会导致每次”fsync”的时间较长(IO阻塞),如果此值过小,将会导致”fsync”的次数较多,这也意味着整体的client请求有一定的延迟.物理server故障,将会导致没有fsync的消息丢失long9223372036854775807 高log.flush.interval.ms当达到下面的时间(ms)时，执行一次强制的flush操作。interval.ms和interval.messages无论哪个达到，都会flush。longnull 高log.flush.offset.checkpoint.interval.ms记录上次把log刷到磁盘的时间点的频率，用来日后的recovery。通常不需要改变long60000 高log.flush.scheduler.interval.ms检查是否需要固化到硬盘的时间间隔long9223372036854775807 高log.retention.bytestopic每个分区的最大文件大小，一个topic的大小限制 = 分区数*log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖loong-1 高log.retention.hours日志保存时间，默认为7天（168小时）。超过这个时间会根据policy处理数据。bytes和minutes无论哪个先达到都会触发int168 高log.retention.minutes数据存储的最大时间超过这个时间会根据log.cleanup.policy设置的策略处理数据，也就是消费端能够多久去消费数据    log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖intnull 高 log.roll.hous当达到下面时间，会强制新建一个segment。这个参数会在日志segment没有达到log.segment.bytes设置的大小，也会强制新建一个segment会int168 高log.roll.jitter.{ms,hours}从logRollTimeMillis抽离的jitter最大数目int0 高log.segment.bytestopic partition的日志存放在某个目录下诸多文件中，这些文件将partition的日志切分成一段一段的；这个属性就是每个文件的最大尺寸；当尺寸达到这个数值时，就会创建新文件。此设置可以由每个topic基础设置时进行覆盖long1G=1024*1024*1024 高log.segment.delet.delay.ms删除文件系统上文件的等待时间，默认是1分钟long6000 高message.max.bytes表示一个服务器能够接收处理的消息的最大字节数，注意这个值producer和consumer必须设置一致，且不要大于fetch.message.max.bytes属性的值该值默认是1000012字节，大概900KB    int1000012 高  min.insync.replicas该属性规定了最小的ISR数。当producer设置request.required.acks为all或-1时，指定副本(replicas)的最小数目（必须确认每一个repica的写数据都是成功的），如果这个数目没有达到，producer会产生异常。int1 高num.io.threads服务器用来处理请求的I/O线程的数目；这个线程数目至少要等于硬盘的个数。int8 高num.network.threads服务器用来处理网络请求的网络线程数目；一般你不需要更改这个属性int3 高num.recovery.threads.per.data.dir每数据目录用于日志恢复启动和关闭冲洗时的线程数量int1 高num.replica.fetchers从leader进行复制消息的线程数，增大这个数值会增加follower的IOint1 高offset.metadata.max.bytes允许client(消费者)保存它们元数据(offset)的最大的数据量int4096(4kb)  offsets.commit.required.acks在offset commit可以接受之前，需要设置确认的数目，一般不需要更改int-1 高offsets.commit.timeout.msoffset commit会延迟直至此超时或所需的副本数都收到offset commit，这类似于producer请求的超时int5000 高offsets.load.buffer.size此设置对应于offset manager在读取缓存offset segment的批量大小（以字节为单位).int5242880 高offsets.retention.check.interval.msoffset管理器检查陈旧offsets的频率long600000(10分钟) 高offsets.topic.num.partitions偏移的提交topic的分区数目。 由于目前不支持部署之后改变，我们建议您使用生产较高的设置（例如，100-200）int50 高offsets.topic.replication.factor复制因子的offset提交topic。较高的设置（例如三个或四个），建议以确保更高的可用性。如果offset topic创建时，broker比复制因子少，offset topic将以较少的副本创建。short3 高offsets.topic.segment.bytesoffset topic的Segment大小。因为它使用压缩的topic，所有Sgment的大小应该保持小一点，以促进更快的日志压实和负载int104857600 高queued.max.requests在网络线程(network threads)停止读取新请求之前，可以排队等待I/O线程处理的最大请求个数。若是等待IO的请求超过这个数值，那么会停止接受外部消息int500 高quota.consumer.default以clientid或consumer group区分的consumer端每秒可以抓取的最大bytelong9223372036854775807 高quota.producer.defaultproducer端每秒可以产生的最大bytelong9223372036854775807 高replica.fetch.max.bytesreplicas每次获取数据的最大字节数int1048576 高replica.fetch.min.bytesfetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件int1 高replica.fetch.wait.max.msreplicas同leader之间通信的最大等待时间，失败了会重试。这个值须小于replica.lag.time.max.ms，以防止低吞吐量主题ISR频繁收缩int500 高replica.high.watermark.checkpoint.interval.ms每一个replica存储自己的high watermark到磁盘的频率，用来日后的recoveryint5000 高replica.socket.timeout.ms复制数据过程中，replica发送给leader的网络请求的socket超时时间,至少等于replica.fetch.wait.max.msint30000 高replica.socket.receive.buffer.bytes复制过程leader接受请求的buffer大小int65536(64*1024) 高replica.lag.time.max.msreplicas响应partition leader的最长等待时间，若是超过这个时间，就将replicas列入ISR(in-sync replicas)，并认为它是死的，不会再加入管理中long10000 高replica.lag.max.messages如果follower落后与leader太多,将会认为此follower[或者说partition relicas]已经失效。 通常,在follower与leader通讯时,因为网络延迟或者链接断开,总会导致replicas中消息同步滞后如果消息之后太多,leader将认为此follower网络延迟较大或者消息吞吐能力有限,将会把此replicas迁移到其他follower中.在broker数量较少,或者网络不足的环境中,建议提高此值.int4000 高request.timeout.msproducer等待响应的最长时间，如果超时将重发几次，最终报错int30000 高socket.receive.buffer.bytessocket用于接收网络请求的缓存大小int102400 高socket.request.max.bytesserver能接受的请求的最大的大小，这是为了防止server跑光内存，不能大于Java堆的大小。int104857600(100*1024*1024) 高socket.send.buffer.bytesserver端用来处理socket连接的SO_SNDBUFF缓冲大小int102400 高controller.socket.timeout.mspartition管理控制器进行备份时，socket的超时时间int30000 高controller.message.queue.sizepartition leader与replicas数据同步时,消息的队列大小int10 高num.partitions每个topic的分区个数，若是在topic创建时候没有指定的话会被topic创建时的指定参数覆盖int1推荐设为8高log.index.interval.bytes当执行一次fetch后，需要一定的空间扫描最近的offset，设置的越大越好，但是也更耗内存一般使用默认值就可以int4096 中log.index.size.max.bytes每个log segment的最大尺寸。注意，如果log尺寸达到这个数值，即使尺寸没有超过log.segment.bytes限制，也需要产生新的log segment。int10485760 中fetch.purgatory.purge.interval.requests非立即答复请求放入purgatory中，当到达或超出interval时认为request completeint1000 中producer.purgatory.purge.interval.requestsproducer请求清除时间int1000 中default.replication.factor一个topic ，默认分区的replication个数 ，不能大于集群中broker的个数。int1 中group.max.session.timeout.ms注册consumer允许的最大超时时间int300000 中group.min.session.timeout.ms注册consumer允许的最小超时时间int6000 中inter.broker.protocol.versionbroker协议版本string0.10.0 中log.cleaner.backoff.ms检查log是否需要clean的时间间隔long15000 中log.cleaner.dedupe.buffer.size日志压缩去重时候的缓存空间，在空间允许的情况下，越大越好long134217728 中log.cleaner.delete.retention.ms保存时间；保存压缩日志的最长时间；也是客户端消费消息的最长时间，同log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据；会被topic创建时的指定时间覆盖。long86400000(一天) 中log.cleaner.enable是否启动压缩日志,当这个属性设置为false时，一旦日志的保存时间或者大小达到上限时，就会被删除；如果设置为true，则当保存属性达到上限时，就会进行压缩booleanfalse 中log.cleaner.threads日志压缩运行的线程数int1 中log.cleaner.io.buffer.load.factor日志清理中hash表的扩大因子，一般不需要修改double0.9 中log.cleaner.io.buffer.sizelog cleaner清除过程中针对日志进行索引化以及精简化所用到的缓存大小。最好设置大点，以提供充足的内存int524288 中log.cleaner.io.max.bytes.per.second进行log compaction时，log cleaner可以拥有的最大I/O数目。这项设置限制了cleaner，以避免干扰活动的请求服务。double1.7976931348623157E308 中log.cleaner.min.cleanable.ratio这项配置控制log compactor试图清理日志的频率（假定[log compaction]是打开的）。默认避免清理压缩超过50%的日志。这个比率绑定了备份日志所消耗的最大空间（50%的日志备份时压缩率为50%）。更高的比率则意味着浪费消耗更少，也就可以更有效的清理更多的空间。这项设置在每个topic设置中可以覆盖double0.5 中log.preallocate是否预创建新文件，windows推荐使用booleanfalse 中log.retention.check.interval.ms检查日志分段文件的间隔时间，以确定是否文件属性是否到达删除要求。long300000 中max.connections.per.ip一个broker允许从每个ip地址连接的最大数目int2147483647=Int.MaxValue 中max.connections.per.ip.overrides每个IP或主机名覆盖连接的默认最大数量string“” 中replica.fetch.backoff.ms复制数据时失败等待时间int1000 中reserved.broker.max.idbroker可以使用的最大ID值int1000 中

topic level 配置

broker级别的参数可以由topic级别的覆写，不是所有的broker参数在topic级别都有对应值 
以下是topic-level的配置选项。server的默认配置在Server Default Property列下给出了，设定这些默认值不会改变原有的设置

PropertyDefaultServer Default PropertyDescriptioncleanup.policydeletelog.cleanup.policy要么是”delete“要么是”compact“； 这个字符串指明了针对旧日志部分的利用方式；默认方式（”delete”）将会丢弃旧的部分当他们的回收时间或者尺寸限制到达时。”compact“将会进行日志压缩delete.retention.ms86400000 (24 hours)log.cleaner.delete.retention.ms对于压缩日志保留的最长时间，也是客户端消费消息的最长时间，通log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据。此项配置可以在topic创建时的置顶参数覆盖flush.messagesnonelog.flush.interval.messages此项配置指定时间间隔：强制进行fsync日志。例如，如果这个选项设置为1，那么每条消息之后都需要进行fsync，如果设置为5，则每5条消息就需要进行一次fsync。一般来说，建议你不要设置这个值。此参数的设置,需要在”数据可靠性”与”性能”之间做必要的权衡.如果此值过大,将会导致每次”fsync”的时间较长(IO阻塞),如果此值过小,将会导致”fsync”的次数较多,这也意味着整体的client请求有一定的延迟.物理server故障,将会导致没有fsync的消息丢失.flush.msNonelog.flush.interval.ms此项配置用来置顶强制进行fsync日志到磁盘的时间间隔；例如，如果设置为1000，那么每1000ms就需要进行一次fsync。一般不建议使用这个选项index.interval.bytes4096log.index.interval.bytes默认设置保证了我们每4096个字节就对消息添加一个索引，更多的索引使得阅读的消息更加靠近，但是索引规模却会由此增大；一般不需要改变这个选项max.message.bytes1000000max.message.byteskafka追加消息的最大尺寸。注意如果你增大这个尺寸，你也必须增大你consumer的fetch 尺寸，这样consumer才能fetch到这些最大尺寸的消息。min.cleanable.dirty.ratio0.5in.cleanable.dirty.ratio此项配置控制log压缩器试图进行清除日志的频率。默认情况下，将避免清除压缩率超过50%的日志。这个比率避免了最大的空间浪费min.insync.replicas1min.insync.replicas当producer设置 acks为-1时，min.insync.replicas指定replicas的最小数目（必须确认每一个repica的写数据都是成功的），如果这个数目没有达到，producer会产生异常。retention.bytesNonelog.retention.bytes如果使用“delete”的retention 策略，这项配置就是指在删除日志之前，日志所能达到的最大尺寸。默认情况下，没有尺寸限制而只有时间限制retention.ms7 dayslog.retention.minutes如果使用“delete”的retention策略，这项配置就是指删除日志前日志保存的时间。segment.bytes1GBlog.segment.byteskafka中log日志是分成一块块存储的，此配置是指log日志划分成块的大小segment.index.bytes10MBlog.index.size.max.bytes此配置是有关offsets和文件位置之间映射的索引文件的大小；一般不需要修改这个配置segment.ms7 dayslog.roll.hours即使log的分块(segment)文件没有达到需要删除、压缩的大小，一旦log 的时间达到这个上限，就会强制新建一个log分块文件segment.jitter.ms0log.roll.jitter.{ms,hours}The maximum jitter to subtract from logRollTimeMillis.