kafka的server.properties文件描述

版本：基于 kafka 2.4.0  http://archive.apache.org/dist/kafka/2.4.0/kafka_2.11-2.4.0.tgz

# Licensed to the Apache Software Foundation (ASF) under one or more （授权给Apache软件基金会(ASF)一个或多个）
# contributor license agreements. See the NOTICE file distributed with （贡献者许可协议。请参阅随附的通知文件）
# this work for additional information regarding copyright ownership.（这是关于版权所有权的附加信息。）
# The ASF licenses this file to You under the Apache License, Version 2.0（ASF根据Apache许可2.0版将此文件授权给您）
# (the "License"); you may not use this file except in compliance with（(“许可证”);除非符合规定，否则您不能使用此文件）
# the License. You may obtain a copy of the License at（许可。你可于）
#
# http://www.apache.org/licenses/LICENSE-2.0（http://www.apache.org/licenses/LICENSE-2.0）
#
# Unless required by applicable law or agreed to in writing, software（除非适用法律要求或经书面同意，软件）
# distributed under the License is distributed on an "AS IS" BASIS,（在许可下发布的是“按现状”发布的，）
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.（没有任何明示或暗示的保证或条件。）
# See the License for the specific language governing permissions and（有关特定语言的管理权限和）
# limitations under the License.（许可的限制。）

# see kafka.server.KafkaConfig for additional details and defaults（看到kafka.server。获取更多的细节和默认值）

上面的意思大概讲述了  ASF批准了Apache许可证的2.0版本，该许可证帮助我们实现了通过协作开源软件开发来提供可靠且寿命长的软件产品的目标。

除非另有明确说明，否则A​​SF产生的所有软件包均根据Apache许可版本2.0隐含许可。具体可以到 http://www.apache.org/licenses/LICENSE-2.0 进行查看。

没啥好说的...

############################# Server Basics #############################

# The id of the broker. This must be set to a unique integer for each broker.（代理的id。必须为每个代理设置一个惟一的整数）

在Kafka集群中，每个broker都有一个唯一的id值用来区分彼此。Kafka在启动时会在zookeeper中/brokers/ids路径下创建一个与当前broker的id为名称的虚节点，Kafka的健康状态检查就依赖于此节点。

当broker下线时，该虚节点会自动删除，其他broker或者客户端通过判断/brokers/ids路径下是否有此broker的id来确定该broker的健康状态。

可以通过配置文件config/server.properties里的broker.id参数来配置broker的id值，默认情况下broker.id值为-1。Kafka broker的id值必须大于等于0时才有可能正常启动，但是这里并不是只能通过配置文件config/server.properties来修改这个值，还可以通过meta.properties文件或者自动生成功能来实现broker的id值的设置。
————————————————
版权声明：本文为CSDN博主「朱小厮」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u013256816/article/details/80546337

broker.id=0

############################# Socket Server Settings #############################

# The address the socket server listens on. It will get the value returned from （套接字服务器监听的地址。它将获得返回的值）
# java.net.InetAddress.getCanonicalHostName() if not configured.（）
# 　　 FORMAT:
# 　　 listeners = listener_name://host_name:port
# 　　 EXAMPLE:
#　　 listeners = PLAINTEXT://your.host.name:9092

#listeners=PLAINTEXT://:9092

# Hostname and port the broker will advertise to producers and consumers. If not set, （代理将向生产者和消费者发布主机名和端口。如果未设置，）
# it uses the value for "listeners" if configured. Otherwise, it will use the value（则在配置时使用“侦听器”的值。）
# returned from java.net.InetAddress.getCanonicalHostName().（否则，它将使用java.net.InetAddress.getCanonicalHostName()返回的值。）
#advertised.listeners=PLAINTEXT://your.host.name:9092

# Maps listener names to security protocols, the default is for them to be the same. See the config documentation for more details（将监听器名称映射到安全协议，默认情况下它们是相同的。）
#listener.security.protocol.map=PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL（有关详细信息，请参阅配置文档listener.security.protocol。map=明文:明文，SSL:SSL,）

# The number of threads that the server uses for receiving requests from the network and sending responses to the network（sasl_明文:sasl_明文，SASL_SSL:SASL_SSL服务器用于从网络接收请求和向网络发送响应的线程数）

默认处理网络请求的线程个数

num.network.threads=3

# The number of threads that the server uses for processing requests, which may include disk I/O（服务器用于处理请求的线程数，可能包括磁盘I/O）

执行磁盘IO操作的默认线程个数

num.io.threads=8

# The send buffer (SO_SNDBUF) used by the socket server（套接字服务器使用的发送缓冲区(SO_SNDBUF)）

socket服务使用的进行发送数据的缓冲区大小，默认100kb

socket.send.buffer.bytes=102400

# The receive buffer (SO_RCVBUF) used by the socket server（套接字服务器使用的接收缓冲区(SO_RCVBUF)）

socket服务使用的进行接受数据的缓冲区大小，默认100kb

socket.receive.buffer.bytes=102400

# The maximum size of a request that the socket server will accept (protection against OOM)（套接字服务器将接受的请求的最大大小(针对OOM的保护)）

socket服务所能够接受的最大的请求量，防止出现OOM(Out of memory)内存溢出，默认值为：100m
（应该是socker server所能接受的一个请求的最大大小，默认为100M）

socket.request.max.bytes=104857600

############################# Log Basics #############################

# A comma separated list of directories under which to store log files（一个逗号分隔的目录列表，用于存储日志文件）

虽然这里叫做 logs（见名知意，认为是存储kafka日志的），但是这里是存储数据和日志的。之所以叫 logs 是因为 kafka文件的后缀为log
log.dirs=/app/ywjcproject/kafka_2.11-2.4.0/logs

# The default number of log partitions per topic. More partitions allow greater（每个主题的默认日志分区数。 ）
# parallelism for consumption, but this will also result in more files across（更多的分区允许更大的并行度，但这也会导致更多的文件跨代理。）
# the brokers.

每一个topic所对应的log的partition分区数目，默认1个。更多的partition数目会提高消费
并行度，但是也会导致在kafka集群中有更多的文件进行传输
（partition就是分布式存储，相当于是把一份数据分开几份来进行存储，即划分块、划分分区的意思）

num.partitions=1

# The number of threads per data directory to be used for log recovery at startup and flushing at shutdown.（每个数据目录用于启动时的日志恢复和关机时的刷新的线程数。）
# This value is recommended to be increased for installations with data dirs located in RAID array.（对于安装RAID阵列中有数据dirs的情况，建议增加此值。）

每一个数据目录用于在启动kafka时恢复数据和在关闭时刷新数据的线程个数。如果kafka数据存储在磁盘阵列中
建议此值可以调整更大。

num.recovery.threads.per.data.dir=1

############################# Internal Topic Settings #############################
# The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state"（组元数据内部主题“_consumer_offsets”和“_transaction_state”的复制因子对于开发测试以外的任何测试）
# For anything other than development testing, a value greater than 1 is recommended to ensure availability such as 3.（建议使用大于1的值来确保可用性，如3。）
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1

############################# Log Flush Policy #############################

# Messages are immediately written to the filesystem but by default we only fsync() to sync（消息被立即写入文件系统，但在默认情况下，我们仅使用fsync()对操作系统缓存进行延迟同步。）
# the OS cache lazily. The following configurations control the flush of data to disk.（以下配置控制数据到磁盘的刷新。）
# There are a few important trade-offs here:（这里有一些重要的权衡:）
# 1. Durability: Unflushed data may be lost if you are not using replication.（1。持久性:如果不使用复制，未刷新的数据可能会丢失。）
# 2. Latency: Very large flush intervals may lead to latency spikes when the flush does occur as there will be a lot of data to flush.（2. 延迟:非常大的刷新间隔可能会导致延迟峰值，因为会有大量数据需要刷新。）
# 3. Throughput: The flush is generally the most expensive operation, and a small flush interval may lead to excessive seeks.（3.吞吐量:刷新通常是最昂贵的操作，一个小的刷新间隔可能导致过多的查找。）
# The settings below allow one to configure the flush policy to flush data after a period of time or（下面的设置允许您配置刷新策略，以便在一段时间后或每N条消息(或同时包含N条消息)刷新数据。）
# every N messages (or both). This can be done globally and overridden on a per-topic basis.（这可以在全局范围内完成，并在每个主题的基础上覆盖。）

# The number of messages to accept before forcing a flush of data to disk（在将数据刷新到磁盘之前要接受的消息数）

消息刷新到磁盘中的消息条数阈值 单位毫秒

#log.flush.interval.messages=10000

# The maximum amount of time a message can sit in a log before we force a flush（在强制刷新之前，消息可以驻留在日志中的最长时间）

消息刷新到磁盘生成一个log数据文件的时间间隔 单位毫秒

#log.flush.interval.ms=1000

############################# Log Retention Policy #############################

# The following configurations control the disposal of log segments. The policy can（以下配置控制日志段的处理。）
# be set to delete segments after a period of time, or after a given size has accumulated.（可以将策略设置为在一段时间之后或在积累了给定的大小之后删除段。）
# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens（只要满足*其中*一个条件，段就会被删除。删除总是发生在日志的末尾。）
# from the end of the log.

# The minimum age of a log file to be eligible for deletion due to age（日志文件的最小删除年龄）

基于时间的策略，删除日志数据的时间，默认保存7天

log.retention.hours=168

# A size-based retention policy for logs. Segments are pruned from the log unless the remaining（基于日志大小的保留策略。除非其余段位于log. retene .bytes下，否则将从日志中删除段。）
# segments drop below log.retention.bytes. Functions independently of log.retention.hours.（功能独立于日志。保持。小时。）

基于大小的策略，1G

#log.retention.bytes=1073741824

# The maximum size of a log segment file. When this size is reached a new log segment will be created.（日志段文件的最大大小。当达到这个大小时，将创建一个新的日志段。）

数据分片策略 1G

log.segment.bytes=1073741824

# The interval at which log segments are checked to see if they can be deleted according（检查日志段以确定是否可以根据其删除的间隔）
# to the retention policies（保留政策）

每隔多长时间检测数据是否达到删除条件

log.retention.check.interval.ms=300000

############################# Zookeeper #############################

# Zookeeper connection string (see zookeeper docs for details).（Zookeeper连接字符串(详见Zookeeper文档)。）
# This is a comma separated host:port pairs, each corresponding to a zk（这是一个逗号分隔的主机:端口对，每个对应一个zk服务器）
# server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".（如。“127.0.0.1:3000 127.0.0.1:3001 127.0.0.1:3002”。）
# You can also append an optional chroot string to the urls to specify the（您还可以向url附加一个可选的chroot字符串，以指定所有kafka znodes的根目录。）
# root directory for all kafka znodes.
zookeeper.connect=localhost:2181

# Timeout in ms for connecting to zookeeper（连接到zookeeper的ms超时）
zookeeper.connection.timeout.ms=6000

############################# Group Coordinator Settings #############################

# The following configuration specifies the time, in milliseconds, that the GroupCoordinator will delay the initial consumer rebalance.（下面的配置指定了GroupCoordinator延迟初始消费者再平衡的时间(以毫秒为单位)。）
# The rebalance will be further delayed by the value of group.initial.rebalance.delay.ms as new members join the group, up to a maximum of max.poll.interval.ms.（随着新成员加入该组织，再平衡将进一步被group.initial.rebalance.delay.ms的值所延迟，其最大值为max.poll.interval.ms。）
# The default value for this is 3 seconds.（默认值是3秒。）
# We override this to 0 here as it makes for a better out-of-the-box experience for development and testing.（我们在这里将其重写为0，因为它为开发和测试提供了更好的开箱即用体验。）
# However, in production environments the default value of 3 seconds is more suitable as this will help to avoid unnecessary, and potentially expensive, rebalances during application startup.（然而，在生产环境中，3秒的默认值更合适，因为这将有助于避免在应用程序启动期间进行不必要的、可能代价高昂的重新平衡。）
group.initial.rebalance.delay.ms=0

Apache Kafka 配置

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处理消息的最大线程数，一般情况下不需要去修改

num.io.threads =8

broker处理磁盘IO的线程数，数值应该大于你的硬盘数

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=60*24 # 一天后删除

数据存储的最大时间超过这个时间会根据log.cleanup.policy设置的策略处理数据，也就是消费端能够多久去消费数据

log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖

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文件”sync”到磁盘之前累积的消息条数,因为磁盘IO操作是一个慢操作,但又是一个”数据可靠性"的必要手段,所以此参数的设置,需要在"数据可靠性"与"性能"之间做必要的权衡.如果此值过大,将会导致每次"fsync"的时间较长(IO阻塞),如果此值过小,将会导致"fsync"的次数较多,这也意味着整体的client请求有一定的延迟.物理server故障,将会导致没有fsync的消息丢失.

log.flush.scheduler.interval.ms =3000

检查是否需要固化到硬盘的时间间隔

log.flush.interval.ms = None

仅仅通过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

(1).producer.properties:生产端的配置文件

#指定kafka节点列表，用于获取metadata，不必全部指定
#需要kafka的服务器地址，来获取每一个topic的分片数等元数据信息。
metadata.broker.list=kafka01:9092,kafka02:9092,kafka03:9092

#生产者生产的消息被发送到哪个block，需要一个分组策略。
#指定分区处理类。默认kafka.producer.DefaultPartitioner，表通过key哈希到对应分区
#partitioner.class=kafka.producer.DefaultPartitioner

#生产者生产的消息可以通过一定的压缩策略（或者说压缩算法）来压缩。消息被压缩后发送到broker集群，
#而broker集群是不会进行解压缩的，broker集群只会把消息发送到消费者集群，然后由消费者来解压缩。
#是否压缩，默认0表示不压缩，1表示用gzip压缩，2表示用snappy压缩。
#压缩后消息中会有头来指明消息压缩类型，故在消费者端消息解压是透明的无需指定。
#文本数据会以1比10或者更高的压缩比进行压缩。
compression.codec=none

#指定序列化处理类，消息在网络上传输就需要序列化，它有String、数组等许多种实现。
serializer.class=kafka.serializer.DefaultEncoder

#如果要压缩消息，这里指定哪些topic要压缩消息，默认empty，表示不压缩。
#如果上面启用了压缩，那么这里就需要设置
#compressed.topics=
#这是消息的确认机制，默认值是0。在面试中常被问到。
#producer有个ack参数，有三个值，分别代表：
#（1）不在乎是否写入成功；
#（2）写入leader成功；
#（3）写入leader和所有副本都成功；
#要求非常可靠的话可以牺牲性能设置成最后一种。
#为了保证消息不丢失，至少要设置为1，也就
#是说至少保证leader将消息保存成功。
#设置发送数据是否需要服务端的反馈,有三个值0,1,-1，分别代表3种状态：
#0: producer不会等待broker发送ack。生产者只要把消息发送给broker之后，就认为发送成功了，这是第1种情况；
#1: 当leader接收到消息之后发送ack。生产者把消息发送到broker之后，并且消息被写入到本地文件，才认为发送成功，这是第二种情况；#-1: 当所有的follower都同步消息成功后发送ack。不仅是主的分区将消息保存成功了，
#而且其所有的分区的副本数也都同步好了，才会被认为发动成功，这是第3种情况。
request.required.acks=0

#broker必须在该时间范围之内给出反馈，否则失败。
#在向producer发送ack之前,broker允许等待的最大时间 ，如果超时,
#broker将会向producer发送一个error ACK.意味着上一次消息因为某种原因
#未能成功(比如follower未能同步成功)
request.timeout.ms=10000

#生产者将消息发送到broker，有两种方式，一种是同步，表示生产者发送一条，broker就接收一条；
#还有一种是异步，表示生产者积累到一批的消息，装到一个池子里面缓存起来，再发送给broker，
#这个池子不会无限缓存消息，在下面，它分别有一个时间限制（时间阈值）和一个数量限制（数量阈值）的参数供我们来设置。
#一般我们会选择异步。
#同步还是异步发送消息，默认“sync”表同步，"async"表异步。异步可以提高发送吞吐量,
#也意味着消息将会在本地buffer中,并适时批量发送，但是也可能导致丢失未发送过去的消息
producer.type=sync

#在async模式下,当message被缓存的时间超过此值后,将会批量发送给broker,
#默认为5000ms
#此值和batch.num.messages协同工作.
queue.buffering.max.ms = 5000

#异步情况下，缓存中允许存放消息数量的大小。
#在async模式下,producer端允许buffer的最大消息量
#无论如何,producer都无法尽快的将消息发送给broker,从而导致消息在producer端大量沉积
#此时,如果消息的条数达到阀值,将会导致producer端阻塞或者消息被抛弃，默认为10000条消息。
queue.buffering.max.messages=20000

#如果是异步，指定每次批量发送数据量，默认为200
batch.num.messages=500

#在生产端的缓冲池中，消息发送出去之后，在没有收到确认之前，该缓冲池中的消息是不能被删除的，
#但是生产者一直在生产消息，这个时候缓冲池可能会被撑爆，所以这就需要有一个处理的策略。
#有两种处理方式，一种是让生产者先别生产那么快，阻塞一下，等会再生产；另一种是将缓冲池中的消息清空。
#当消息在producer端沉积的条数达到"queue.buffering.max.meesages"后阻塞一定时间后,
#队列仍然没有enqueue(producer仍然没有发送出任何消息)
#此时producer可以继续阻塞或者将消息抛弃,此timeout值用于控制"阻塞"的时间
#-1: 不限制阻塞超时时间，让produce一直阻塞,这个时候消息就不会被抛弃
#0: 立即清空队列,消息被抛弃
queue.enqueue.timeout.ms=-1

#当producer接收到error ACK,或者没有接收到ACK时,允许消息重发的次数
#因为broker并没有完整的机制来避免消息重复,所以当网络异常时(比如ACK丢失)
#有可能导致broker接收到重复的消息,默认值为3.
message.send.max.retries=3

#producer刷新topic metada的时间间隔,producer需要知道partition leader
#的位置,以及当前topic的情况
#因此producer需要一个机制来获取最新的metadata,当producer遇到特定错误时,
#将会立即刷新
#(比如topic失效,partition丢失,leader失效等),此外也可以通过此参数来配置
#额外的刷新机制，默认值600000
topic.metadata.refresh.interval.ms=60000

(2).consumer.properties:消费端的配置文件

#消费者集群通过连接Zookeeper来找到broker。
#zookeeper连接服务器地址
zookeeper.connect=zk01:2181,zk02:2181,zk03:2181

#zookeeper的session过期时间，默认5000ms，用于检测消费者是否挂掉
zookeeper.session.timeout.ms=5000

#当消费者挂掉，其他消费者要等该指定时间才能检查到并且触发重新负载均衡
zookeeper.connection.timeout.ms=10000

#这是一个时间阈值。
#指定多久消费者更新offset到zookeeper中。
#注意offset更新时基于time而不是每次获得的消息。
#一旦在更新zookeeper发生异常并重启，将可能拿到已拿到过的消息
zookeeper.sync.time.ms=2000

#指定消费
group.id=xxxxx

#这是一个数量阈值，经测试是500条。
#当consumer消费一定量的消息之后,将会自动向zookeeper提交offset信息#注意offset信息并不是每消费一次消息就向zk提交
#一次,而是现在本地保存(内存),并定期提交,默认为true
auto.commit.enable=true

# 自动更新时间。默认60 * 1000
auto.commit.interval.ms=1000

# 当前consumer的标识,可以设定,也可以有系统生成,
#主要用来跟踪消息消费情况,便于观察
conusmer.id=xxx

# 消费者客户端编号，用于区分不同客户端，默认客户端程序自动产生
client.id=xxxx

# 最大取多少块缓存到消费者(默认10)
queued.max.message.chunks=50

# 当有新的consumer加入到group时,将会reblance,此后将会
#有partitions的消费端迁移到新  的consumer上,如果一个
#consumer获得了某个partition的消费权限,那么它将会向zk
#注册 "Partition Owner registry"节点信息,但是有可能
#此时旧的consumer尚没有释放此节点, 此值用于控制,
#注册节点的重试次数.
rebalance.max.retries=5

#每拉取一批消息的最大字节数
#获取消息的最大尺寸,broker不会像consumer输出大于
#此值的消息chunk 每次feth将得到多条消息,此值为总大小,
#提升此值,将会消耗更多的consumer端内存
fetch.min.bytes=6553600

#当消息的尺寸不足时,server阻塞的时间,如果超时,
#消息将立即发送给consumer
#数据一批一批到达，如果每一批是10条消息，如果某一批还
#不到10条，但是超时了，也会立即发送给consumer。
fetch.wait.max.ms=5000
socket.receive.buffer.bytes=655360

# 如果zookeeper没有offset值或offset值超出范围。
#那么就给个初始的offset。有smallest、largest、
#anything可选，分别表示给当前最小的offset、
#当前最大的offset、抛异常。默认largest
auto.offset.reset=smallest

# 指定序列化处理类
derializer.class=kafka.serializer.DefaultDecoder

(3).server.properties:服务端的配置文件

#broker的全局唯一编号，不能重复
broker.id=0

#用来监听链接的端口，producer或consumer将在此端口建立连接
port=9092

#处理网络请求的线程数量，也就是接收消息的线程数。
#接收线程会将接收到的消息放到内存中，然后再从内存中写入磁盘。
num.network.threads=3

#消息从内存中写入磁盘是时候使用的线程数量。
#用来处理磁盘IO的线程数量
num.io.threads=8

#发送套接字的缓冲区大小
socket.send.buffer.bytes=102400

#接受套接字的缓冲区大小
socket.receive.buffer.bytes=102400

#请求套接字的缓冲区大小
socket.request.max.bytes=104857600

#kafka运行日志存放的路径
log.dirs=/export/servers/logs/kafka

#topic在当前broker上的分片个数
num.partitions=2

#我们知道segment文件默认会被保留7天的时间，超时的话就
#会被清理，那么清理这件事情就需要有一些线程来做。这里就是
#用来设置恢复和清理data下数据的线程数量
num.recovery.threads.per.data.dir=1

#segment文件保留的最长时间，默认保留7天（168小时），
#超时将被删除，也就是说7天之前的数据将被清理掉。
log.retention.hours=168

#滚动生成新的segment文件的最大时间
log.roll.hours=168

#日志文件中每个segment的大小，默认为1G
log.segment.bytes=1073741824

#上面的参数设置了每一个segment文件的大小是1G，那么
#就需要有一个东西去定期检查segment文件有没有达到1G，
#多长时间去检查一次，就需要设置一个周期性检查文件大小
#的时间（单位是毫秒）。
log.retention.check.interval.ms=300000

#日志清理是否打开
log.cleaner.enable=true

#broker需要使用zookeeper保存meta数据
zookeeper.connect=zk01:2181,zk02:2181,zk03:2181

#zookeeper链接超时时间
zookeeper.connection.timeout.ms=6000

#上面我们说过接收线程会将接收到的消息放到内存中，然后再从内存
#写到磁盘上，那么什么时候将消息从内存中写入磁盘，就有一个
#时间限制（时间阈值）和一个数量限制（数量阈值），这里设置的是
#数量阈值，下一个参数设置的则是时间阈值。
#partion buffer中，消息的条数达到阈值，将触发flush到磁盘。
log.flush.interval.messages=10000

#消息buffer的时间，达到阈值，将触发将消息从内存flush到磁盘，
#单位是毫秒。
log.flush.interval.ms=3000

#删除topic需要server.properties中设置delete.topic.enable=true否则只是标记删除
delete.topic.enable=true

#此处的host.name为本机IP(重要),如果不改,则客户端会抛出:
#Producer connection to localhost:9092 unsuccessful 错误!
host.name=kafka01

advertised.host.name=192.168.239.128