kafka-保姆级配置说明(producer)

配置说明的最后一部分；

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