配置说明的最后一部分；

##指定kafka集群的列表，以“,”分割，格式：“host:port,host:port”
##此列表用于producer（consumer）初始化连接使用，server列表可以为kafka集群的子集
##通过此servers列表，client端用于发现cluster的成员全拓扑以及获取集群的meta信息。
##为了避免某个bootstrap失效而无法初始化client，建议此servers列表中server个数>3
##此servers为kafka brokers，而非zookeeper
bootstrap.servers=
##key、value序列化类，必须实现Serializer接口
##当key、value不是string时，需要指定
##如果指定了相应的Serializer，那么也要求consumer端对应配置相应的Deserializer
#key.serializer=
#value.serializer=
##标识producer，仅用于server端追踪请求。默认值为""，通常不需要指定
##client.id=
##消息分区的算法类，默认为：
##org.apache.kafka.clients.producer.internals.DefaultPartitioner
##即根据key进行hash分区。
#partitioner.class=
 
##producer发送消息后，在确认请求完成之前需要partition leader收到的ack的数量。
##它用来控制已发送消息的持久性。默认值为：1
##acks=0 ：表示producer不需要等到broker任何ack。消息将会立即添加到socket buffer并认定为此消息已发送。
##这将不能保证broker最终一定能够接收到消息并可靠的持久化，
##在此情况下，“retries”配置项也将不生效（即使发送是底层传输通道遇到error，且错误情况也不会对client可见）
##每个消息的反馈信息中offset值总为-1。
##这被认为是一种最高效的传输、确认机制，也是数据担保能力最弱的机制。(当producer端进程退出即可能导致消息丢失)
##acks=1：表示当partition leader收到消息且写入log文件后，即确认为消息请求已完成（向client端反馈ACK）。
##此时，leader不会等待任何replicas（ISR followers）同步完毕。
##这种情况下，当leader在ACK此消息之后失效，且此时followers尚未同步到此消息时，那么此消息将意味着丢失。
##这被认为是一种最通用的传输、确认机制，兼顾数据传输效率和数据担保能力（当partition leader失效时可能导致消息丢失）
##acks=all：当leader接收到消息后，等待所有的ISR followers同步消息，直到所有的ISR都确认收到消息（且写入log文件）以后，
##leader才会向producer反馈ACK，在此过程中producer将一直等待。（如果消息发送失败，producer将会重试，直到超时）
##这被认为是一种担保能力最强、但传输效率最低的机制。
##（除非broker磁盘刷新率较低，且只有leader在线，且在fsync期间物理失效，否则几乎不会丢失数据）
acks=1
 
##单位字节，默认为：32M，建议值为：2097152 （即2M）
##producer端缓存亟待发送消息的内存最大值；
##如果消息发送的速度（调用send方法）比底层IO通道传输的速度高，那么在buffer溢出之前，
##producer的发送操作（send）将会阻塞或者抛出异常，直到buffer空闲。（取决于“block.on.buffer.full”）
##此值的设置，取决于producer与broker端的IO通讯效率，接近“网络IO”的传输效率是最佳状态；
##较大的值，意味着当buffer溢出后客户端等待的时间更长；较小的值，意味着网络IO传输效能较低。
buffer.memory=33554432
 
 
##当producer发送消息时，遇到底层IO异常时，重试发送的次数；默认为0，表示不重发。
##重发，可能会导致消息乱序的问题。
##（底层连接基于NIO，则允许发送多次请求，以及依次收到响应；而不是阻塞模式的request-response模式）
retries=1
##retry操作的backoff时间，即每次retry之前wait的时间
retry.backoff.ms=100
 
##producer会尽可能的将相同partiton的消息批量发送，以提高发送效率（ACK确认次数减少）
##批量发送，对client和broker都有较大的性能提升。
##此参数用于控制单次批量发送的最大数量量，单位：字节，如果设置为0则表示关闭批量发送。
##发送给broker的请求可以包含多个batches，每个batch对应一个partion（有多条消息组成）
##在发送消息时，总是创建batch.size大小的buffer用于保存消息；所以较大的值将会消耗更高的内存
batch.size=16384
 
##语义有点类似于TCP中的“Nagle”算法（封包传输机制）
##当我们开启batch.size设置时，且buffer中的消息量达到batch.size时，消息将会立即批量发送；
##但是如果buffer中消息量不足batch.size时，则等待“linger.ms”时间后再发送，此期间寄希望获得更多的消息，以达到批量发送的目的。
##此值默认为0，表示“不等待”（no delay）。
linger.ms=0
 
##当buffer溢出时、metadata不可用（即因为broker端leader选举等，无法获取最新的metadata），
##将会导致producer的send方法阻塞，此值用于控制阻塞的最长时间。
##用户自定的serializers处理耗时、partitioner计算耗时，则不包含在内。
max.block.ms=60000
 
##单次请求所允许的最大数据量：用于限制每个请求所能包含的batches个数、消息的个数。
##当然也可以用来限制每个消息的最大尺寸，以避免发送“huge”的请求。
max.request.size=1048576
 
##用于控制client等待响应的最大时间
##当超时后，请求将会被重试；如果重试次数已达到阀值，则认为请求失败。
request.timeout.ms=30000
 
##用于限定broker端leader等待followers反馈ACK以满足“acks”配额要求的最大等待时间。
##此值不包含producer到broker的网络传输耗时。
##当leader在限定时间内无法获取满足配额要求的acks时，将会返回error。（但已经执行的数据并不撤销）
timeout.ms=30000
 
##在客户端单个连接上允许“尚未ACK”的请求的最大个数，
##当此连接上“已发送”、“尚未确认”的请求个数达到此值时，client将会阻塞（max.block.ms）。
max.in.flight.requests.per.connection=5
 
##客户端在发送实际消息之前，比如获取broker端的meta信息：包括指定topic的parttions列表以及所位于的broker地址
##此值用于控制获取metadata的超时时间
metadata.fetch.timeout.ms=60000
 
##因为broker集群的变迁，metadata会不断变化，比如leader的迁移等。
##此值用于控制client端强制刷新（重新获取）metadata的时间间隔。
##当client发送消息遇到异常时（比如partition leader不可用）也会尝试立即刷新metadata。
metadata.max.age.ms=300000
 
##底层IO连接空闲的最大时间，单位：毫秒
##connections.max.idle.ms=540000
##底层IO连接通道，在重建连接时的backoff时间（即间歇等待的时间），以避免频繁重建连接且失败的情况。
reconnect.backoff.ms=50
 
##是否启用压缩机制，建议关闭
compression.type=none

  ----------------------------------------------------------------------------------------------

深耕运维行业多年，擅长linux、容器云原生、运维自动化等方面。
承接各类运维环境部署、方案设计/实施、服务代运维工作，欢迎沟通交流！

（V： xiaoxiangbj2013 ） ！