kafka 生产者 配置 说明

数据流通道

2019-03-24

25

0

技术:kafka

运行环境:centos6.8

demo功能:提供一个kafka生产者配置

生产者配置

##指定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
 
 

欢迎添加微信,互相学习↑↑↑ -_-

发表评论

全部评论:0条

白老虎

programming is not only to solve problems, ways to think