KAFKA目录结构
来源:互联网 发布:深圳淘宝拍照 编辑:程序博客网 时间:2024/06/05 20:29
找到kafka的安装目录
find / -name kafka* -type d
[root@DockerHostconfig]# cd/wls/kafka_2.11-0.8.2.1/config
[root@DockerHostconfig]# ll
total28
-rw-r--r--1 root root 1199 Feb 27 2015consumer.properties
-rw-r--r--1 root root 3846 Feb 27 2015log4j.properties
-rw-r--r--1 root root 2228 Feb 27 2015producer.properties
-rw-r--r--1 root root 686 Nov 24 09:48 server.properties
-rw-r--r--1 root root 3325 Feb 27 2015test-log4j.properties
-rw-r--r--1 root root 993 Feb 27 2015 tools-log4j.properties
-rw-r--r--1 root root 1023 Feb 27 2015zookeeper.properties
[root@DockerHostconfig]# catserver.properties
port=9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=104857600
socket.receive.buffer.bytes=104857600
socket.request.max.bytes=1048576000
#log.dirs=/wls/kafka-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=false
zookeeper.connect=10.30.12.135:2181,10.30.12.136:2181,10.30.12.137:2181
zookeeper.connection.timeout.ms=60000
#broker.id=135
#host.name=10.30.12.135
#broker.id=135
#host.name=10.30.12.135
#broker.id=136
#host.name=10.30.12.136
#broker.id=136
#host.name=10.30.12.136
broker.id=135
host.name=10.30.12.135
log.dirs=/data/kafka-logs135
[root@DockerHostconfig]# cd /data/
[root@DockerHostdata]# ll
total96
lrwxrwxrwx 1 root 5001 6 Oct 24 15:31 conf -> config
drwxrwsr-x333 root 5001 28672 Dec 23 18:25kafka-logs135
drwxrwsr-x331 root 5001 28672 Dec 23 18:25kafka-logs136
drwxrwsr-x333 root 5001 28672 Dec 23 18:25kafka-logs137
[root@DockerHostdata]#cd kafka-logs135
[root@DockerHostkafka-logs135]# ll
drwxrwsr-x2 root 5001 4096 Dec 15 04:45order-topic-local1-0
drwxrwsr-x2 root 5001 4096 Dec 2 00:52order-topic-local1-1
drwxrwsr-x2 root 5001 4096 Dec 15 22:40 order-topic-local1-2
drwxrwsr-x2 root 5001 4096 Dec 15 04:45 order-topic-local1-3
[root@DockerHostkafka-logs135]#cd order-topic-local1-0
[root@DockerHostorder-topic-local1-0]# ll
total0
-rw-r--r--1 root 5001 10485760 Dec 14 17:2900000000000000000141.index
-rw-r--r--1 root 5001 0 Dec 14 17:29 00000000000000000141.log
server.properties中所有配置参数说明(解释)如下列表:
参数
说明(解释)
broker.id =0
每一个broker在集群中的唯一表示,要求是正数。当该服务器的IP地址发生改变时,broker.id没有变化,则不会影响consumers的消息情况
log.dirs=/data/kafka-logs
kafka数据的存放地址,多个地址的话用逗号分割,多个目录分布在不同磁盘上可以提高读写性能 /data/kafka-logs-1,/data/kafka-logs-2
port =9092
broker server服务端口
message.max.bytes =6525000
表示消息体的最大大小,单位是字节
num.network.threads =4
broker处理消息的最大线程数,一般情况下数量为cpu核数
num.io.threads =8
broker处理磁盘IO的线程数,数值为cpu核数2倍
background.threads =4
一些后台任务处理的线程数,例如过期消息文件的删除等,一般情况下不需要去做修改
queued.max.requests =500
等待IO线程处理的请求队列最大数,若是等待IO的请求超过这个数值,那么会停止接受外部消息,应该是一种自我保护机制。
host.name
broker的主机地址,若是设置了,那么会绑定到这个地址上,若是没有,会绑定到所有的接口上,并将其中之一发送到ZK,一般不设置
socket.send.buffer.bytes=100*1024
socket的发送缓冲区,socket的调优参数SO_SNDBUFF
socket.receive.buffer.bytes =100*1024
socket的接受缓冲区,socket的调优参数SO_RCVBUFF
socket.request.max.bytes =100*1024*1024
socket请求的最大数值,防止serverOOM,message.max.bytes必然要小于socket.request.max.bytes,会被topic创建时的指定参数覆盖
log.segment.bytes =1024*1024*1024
topic的分区是以一堆segment文件存储的,这个控制每个segment的大小,会被topic创建时的指定参数覆盖
log.roll.hours =24*7
这个参数会在日志segment没有达到log.segment.bytes设置的大小,也会强制新建一个segment会被 topic创建时的指定参数覆盖
log.cleanup.policy = delete
日志清理策略选择有:delete和compact主要针对过期数据的处理,或是日志文件达到限制的额度,会被 topic创建时的指定参数覆盖
log.retention.minutes=300
或
log.retention.hours=24
数据文件保留多长时间, 存储的最大时间超过这个时间会根据log.cleanup.policy设置数据清除策略
log.retention.bytes和log.retention.minutes或log.retention.hours任意一个达到要求,都会执行删除
有2删除数据文件方式:
按照文件大小删除:log.retention.bytes
按照2中不同时间粒度删除:分别为分钟,小时
log.retention.bytes=-1
topic每个分区的最大文件大小,一个topic的大小限制 = 分区数*log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个达到要求,都会执行删除,会被topic创建时的指定参数覆盖
log.retention.check.interval.ms=5minutes
文件大小检查的周期时间,是否处罚 log.cleanup.policy中设置的策略
log.cleaner.enable=false
是否开启日志清理
log.cleaner.threads = 2
日志清理运行的线程数
log.cleaner.io.max.bytes.per.second=None
日志清理时候处理的最大大小
log.cleaner.dedupe.buffer.size=500*1024*1024
日志清理去重时候的缓存空间,在空间允许的情况下,越大越好
log.cleaner.io.buffer.size=512*1024
日志清理时候用到的IO块大小一般不需要修改
log.cleaner.io.buffer.load.factor =0.9
日志清理中hash表的扩大因子一般不需要修改
log.cleaner.backoff.ms =15000
检查是否处罚日志清理的间隔
log.cleaner.min.cleanable.ratio=0.5
日志清理的频率控制,越大意味着更高效的清理,同时会存在一些空间上的浪费,会被topic创建时的指定参数覆盖
log.cleaner.delete.retention.ms =1day
对于压缩的日志保留的最长时间,也是客户端消费消息的最长时间,同log.retention.minutes的区别在于一个控制未压缩数据,一个控制压缩后的数据。会被topic创建时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024
对于segment日志的索引文件大小限制,会被topic创建时的指定参数覆盖
log.index.interval.bytes =4096
当执行一个fetch操作后,需要一定的空间来扫描最近的offset大小,设置越大,代表扫描速度越快,但是也更好内存,一般情况下不需要搭理这个参数
log.flush.interval.messages=None
例如log.flush.interval.messages=1000
表示每当消息记录数达到1000时flush一次数据到磁盘
log文件”sync”到磁盘之前累积的消息条数,因为磁盘IO操作是一个慢操作,但又是一个”数据可靠性"的必要手段,所以此参数的设置,需要在"数据可靠性"与"性能"之间做必要的权衡.如果此值过大,将会导致每次"fsync"的时间较长(IO阻塞),如果此值过小,将会导致"fsync"的次数较多,这也意味着整体的client请求有一定的延迟.物理server故障,将会导致没有fsync的消息丢失.
log.flush.scheduler.interval.ms =3000
检查是否需要固化到硬盘的时间间隔
log.flush.interval.ms = None
例如:log.flush.interval.ms=1000
表示每间隔1000毫秒flush一次数据到磁盘
仅仅通过interval来控制消息的磁盘写入时机,是不足的.此参数用于控制"fsync"的时间间隔,如果消息量始终没有达到阀值,但是离上一次磁盘同步的时间间隔达到阀值,也将触发.
log.delete.delay.ms =60000
文件在索引中清除后保留的时间一般不需要去修改
log.flush.offset.checkpoint.interval.ms =60000
控制上次固化硬盘的时间点,以便于数据恢复一般不需要去修改
auto.create.topics.enable =true
是否允许自动创建topic,若是false,就需要通过命令创建topic
default.replication.factor =1
是否允许自动创建topic,若是false,就需要通过命令创建topic
num.partitions =1
每个topic的分区个数,若是在topic创建时候没有指定的话会被topic创建时的指定参数覆盖
以下是kafka中Leader,replicas配置参数
controller.socket.timeout.ms =30000
partition leader与replicas之间通讯时,socket的超时时间
controller.message.queue.size=10
partition leader与replicas数据同步时,消息的队列尺寸
replica.lag.time.max.ms =10000
replicas响应partition leader的最长等待时间,若是超过这个时间,就将replicas列入ISR(in-sync replicas),并认为它是死的,不会再加入管理中
replica.lag.max.messages =4000
如果follower落后与leader太多,将会认为此follower[或者说partition relicas]已经失效
##通常,在follower与leader通讯时,因为网络延迟或者链接断开,总会导致replicas中消息同步滞后
##如果消息之后太多,leader将认为此follower网络延迟较大或者消息吞吐能力有限,将会把此replicas迁移
##到其他follower中.
##在broker数量较少,或者网络不足的环境中,建议提高此值.
replica.socket.timeout.ms=30*1000
follower与leader之间的socket超时时间
replica.socket.receive.buffer.bytes=64*1024
leader复制时候的socket缓存大小
replica.fetch.max.bytes =1024*1024
replicas每次获取数据的最大大小
replica.fetch.wait.max.ms =500
replicas同leader之间通信的最大等待时间,失败了会重试
replica.fetch.min.bytes =1
fetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件
num.replica.fetchers=1
leader进行复制的线程数,增大这个数值会增加follower的IO
replica.high.watermark.checkpoint.interval.ms =5000
每个replica检查是否将最高水位进行固化的频率
controlled.shutdown.enable =false
是否允许控制器关闭broker ,若是设置为true,会关闭所有在这个broker上的leader,并转移到其他broker
controlled.shutdown.max.retries =3
控制器关闭的尝试次数
controlled.shutdown.retry.backoff.ms =5000
每次关闭尝试的时间间隔
leader.imbalance.per.broker.percentage =10
leader的不平衡比例,若是超过这个数值,会对分区进行重新的平衡
leader.imbalance.check.interval.seconds =300
检查leader是否不平衡的时间间隔
offset.metadata.max.bytes
客户端保留offset信息的最大空间大小
kafka中zookeeper参数配置
zookeeper.connect = localhost:2181
zookeeper集群的地址,可以是多个,多个之间用逗号分割 hostname1:port1,hostname2:port2,hostname3:port3
zookeeper.session.timeout.ms=6000
ZooKeeper的最大超时时间,就是心跳的间隔,若是没有反映,那么认为已经死了,不易过大
zookeeper.connection.timeout.ms =6000
ZooKeeper的连接超时时间
zookeeper.sync.time.ms =2000
ZooKeeper集群中leader和follower之间的同步实际那
源文档 <http://blog.csdn.net/lizhitao/article/details/25667831>
在partition中如何通过offset查找message
例如读取offset=368776的message,需要通过下面2个步骤查找。
- 第一步查找segment file
上述图2为例,其中00000000000000000000.index表示最开始的文件,起始偏移量(offset)为0.第二个文件00000000000000368769.index的消息量起始偏移量为368770 = 368769 + 1.同样,第三个文件00000000000000737337.index的起始偏移量为737338=737337 + 1,其他后续文件依次类推,以起始偏移量命名并排序这些文件,只要根据offset **二分查找**文件列表,就可以快速定位到具体文件。
当offset=368776时定位到00000000000000368769.index|log - 第二步通过segment file查找message
通过第一步定位到segment file,当offset=368776时,依次定位到00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址,然后再通过00000000000000368769.log顺序查找直到offset=368776为止。
从上述图3可知这样做的优点,segment indexfile采取稀疏索引存储方式,它减少索引文件大小,通过mmap可以直接内存操作,稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间,但查找起来需要消耗更多的时间。
源文档 <http://blog.csdn.net/opensure/article/details/46048589>
4.总结
Kafka高效文件存储设计特点
- Kafka把topic中一个parition大文件分成多个小文件段,通过多个小文件段,就容易定期清除或删除已经消费完文件,减少磁盘占用。
- 通过索引信息可以快速定位message和确定response的最大大小。
- 通过index元数据全部映射到memory,可以避免segment file的IO磁盘操作。
- 通过索引文件稀疏存储,可以大幅降低index文件元数据占用空间大小。
源文档 <http://blog.csdn.net/opensure/article/details/46048589>
如果auto.commit.enable=true,当consumer fetch了一些数据但还没有完全处理掉的时候,刚好到commitinterval出发了提交offset操作,接着consumercrash掉了。这时已经fetch的数据还没有处理完成但已经被commit掉,因此没有机会再次被处理,数据丢失。
源文档 <http://kane-xie.iteye.com/blog/2225085>
Broker Configs
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:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper允许你增加一个“chroot”路径,将集群中所有kafka数据存放在特定的路径下。当多个Kafka集群或者其他应用使用相同ZooKeeper集群时,可以使用这个方式设置数据存放路径。这种方式的实现可以通过这样设置连接字符串格式,如下所示:
hostname1:port1,hostname2:port2,hostname3:port3/chroot/path
这样设置就将所有kafka集群数据存放在/chroot/path路径下。注意,在你启动broker之前,你必须创建这个路径,并且consumers必须使用相同的连接格式。
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基础设置时进行覆盖。
查看 the per-topic configuration section
log.roll.hours
24 * 7
即使文件没有到达log.segment.bytes,只要文件创建时间到达此属性,就会创建新文件。这个设置也可以有topic层面的设置进行覆盖;
查看the per-topic configuration section
log.cleanup.policy
delete
log.retention.minutes和log.retention.hours
7 days
每个日志文件删除之前保存的时间。默认数据保存时间对所有topic都一样。
log.retention.minutes和 log.retention.bytes都是用来设置删除日志文件的,无论哪个属性已经溢出。
这个属性设置可以在topic基本设置时进行覆盖。
查看the per-topic configuration section
log.retention.bytes
-1
每个topic下每个partition保存数据的总量;注意,这是每个partitions的上限,因此这个数值乘以partitions的个数就是每个topic保存的数据总量。同时注意:如果log.retention.hours和log.retention.bytes都设置了,则超过了任何一个限制都会造成删除一个段文件。
注意,这项设置可以由每个topic设置时进行覆盖。
查看the per-topic configuration section
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设置中可以覆盖。
查看the per-topic configuration section。
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
这项设置与批量尺寸相关,当从offsets segment中读取时使用。
offsets.commit.required.acks
-1
在offset commit可以接受之前,需要设置确认的数目,一般不需要更改
Property
Default
Server Default Property
Description
cleanup.policy
delete
log.cleanup.policy
要么是”delete“要么是”compact“;这个字符串指明了针对旧日志部分的利用方式;默认方式("delete")将会丢弃旧的部分当他们的回收时间或者尺寸限制到达时。”compact“将会进行日志压缩
delete.retention.ms
86400000 (24 hours)
log.cleaner.delete.retention.ms
对于压缩日志保留的最长时间,也是客户端消费消息的最长时间,通log.retention.minutes的区别在于一个控制未压缩数据,一个控制压缩后的数据。此项配置可以在topic创建时的置顶参数覆盖
flush.messages
None
log.flush.interval.messages
此项配置指定时间间隔:强制进行fsync日志。例如,如果这个选项设置为1,那么每条消息之后都需要进行fsync,如果设置为5,则每5条消息就需要进行一次fsync。一般来说,建议你不要设置这个值。此参数的设置,需要在"数据可靠性"与"性能"之间做必要的权衡.如果此值过大,将会导致每次"fsync"的时间较长(IO阻塞),如果此值过小,将会导致"fsync"的次数较多,这也意味着整体的client请求有一定的延迟.物理server故障,将会导致没有fsync的消息丢失.
flush.ms
None
log.flush.interval.ms
此项配置用来置顶强制进行fsync日志到磁盘的时间间隔;例如,如果设置为1000,那么每1000ms就需要进行一次fsync。一般不建议使用这个选项
index.interval.bytes
4096
log.index.interval.bytes
默认设置保证了我们每4096个字节就对消息添加一个索引,更多的索引使得阅读的消息更加靠近,但是索引规模却会由此增大;一般不需要改变这个选项
max.message.bytes
1000000
max.message.bytes
kafka追加消息的最大尺寸。注意如果你增大这个尺寸,你也必须增大你consumer的fetch尺寸,这样consumer才能fetch到这些最大尺寸的消息。
min.cleanable.dirty.ratio
0.5
min.cleanable.dirty.ratio
此项配置控制log压缩器试图进行清除日志的频率。默认情况下,将避免清除压缩率超过50%的日志。这个比率避免了最大的空间浪费
min.insync.replicas
1
min.insync.replicas
当producer设置request.required.acks为-1时,min.insync.replicas指定replicas的最小数目(必须确认每一个repica的写数据都是成功的),如果这个数目没有达到,producer会产生异常。
retention.bytes
None
log.retention.bytes
如果使用“delete”的retention 策略,这项配置就是指在删除日志之前,日志所能达到的最大尺寸。默认情况下,没有尺寸限制而只有时间限制
retention.ms
7 days
log.retention.minutes
如果使用“delete”的retention策略,这项配置就是指删除日志前日志保存的时间。
segment.bytes
1GB
log.segment.bytes
kafka中log日志是分成一块块存储的,此配置是指log日志划分成块的大小
segment.index.bytes
10MB
log.index.size.max.bytes
此配置是有关offsets和文件位置之间映射的索引文件的大小;一般不需要修改这个配置
segment.ms
7 days
log.roll.hours
即使log的分块文件没有达到需要删除、压缩的大小,一旦log的时间达到这个上限,就会强制新建一个log分块文件
segment.jitter.ms
0
log.roll.jitter.{ms,hours}
The maximum jitter to subtract from logRollTimeMillis.
- KAFKA目录结构
- Kafka源码中clients的目录结构
- Kafka学习笔记:在zookeeper中考察kafka目录结构
- kafka迁移数据目录
- Kafka log结构解读
- kafka拓扑结构
- 目录结构
- 目录结构
- 目录结构
- 目录结构
- 目录结构
- 目录结构
- 目录结构
- 目录结构
- [002]kafka消息流通结构
- Kafka学习(二):Kafka的基本结构和概念
- kafka入门(二)——kafka的逻辑结构
- Kafka学习(二):Kafka的基本结构和概念
- 浅谈Angular的 $http, $q, defer, promise
- 【移动端】判断PC端还是手机端
- 微信小程序开发—(十五)audio音频播放
- Thinkphp分布式数据库
- MapReduce运行中遇到的问题
- KAFKA目录结构
- Java注解实战
- 选项卡 新闻导航
- 微信小程序学习日志1
- rex 传文件改变用户属主
- 腾讯亿级排行榜系统实践及挑战
- 一份接地气的数据方案!——能源化工生产管理数据分析
- 寻找最大数
- 机器学习知识点(二十八)Beta分布和Dirichlet分布理解