标签：发送 producer 生产者 broker Kafka 剖析 参数 消息 leader
1.acks
kafka producer向topic分区leader副本所在的broker发送消息时，leader副本会向producer发出应答。根据不同的ack参数，应答方式也不同。
acks = 0 ，producer发完消息，不等待broker端返回，直接开始发送下一条数据，很显然，如果消息发送到broker的过程中，出了问题，这条消息就丢失了，因此生产环境不建议把ack设置成0，但是这种情况下，kafka的吞吐是最高的，因为它不需要等待broker端返回结果。
acks = -1（all） ，producer发送完消息，必须要等leader副本所在的broker将消息持久化到本地磁盘，同时ISR中所有的副本和leader完成消息同步，这时候才通知producer可以继续发送消息。很显然，这种情况有点极端，吞吐量最低，但是它的安全性最高，很多不能允许消息丢失的场景可以将acks设置成-1。
ack = 1，producer发完消息，必须要等待leader副本所在的broker将数据写入本地日志，才返回消息告诉producer，我已经成功接收，这时，producer才接着发送消息。这其实上面两种方案的折中，不是严格要求消息不能丢失的场景可以考虑将acks设置成1。但是，如果在leader发送acks的时候leader副本宕机，这时候producer并不知道，producer接着发送消息，所以当leader宕机时会导致消息的丢失。
2.buffer.memory
我们知道，producer在将数据发往broker时，经过拦截器，分区器，序列化器等一系列操作，会将数据缓存到消息累加器RecordAccumulator，然后由一个专门的线程负责从消息累加器拉取数据。这个参数值得就是消息累加器的内存大小，默认时32M。当生产者往缓存中发送数据的速度大于服务器拉取的速度，缓冲区中数据就会越来越多，最后导致空间不足，这时候要么抛出异常让用户参与处理，要么send（）方法阻塞。
3.compression.type
该参数用于指定生产者对发送的消息采取的压缩类型，默认时不采取压缩，目前kafka支持三种压缩格式：LZ4，snappy和GZIP。这三种压缩格式的压缩比LZ4最高。若要使用压缩，可以配置参数
properties.put(ProducerConfig .COMPRESSION_TYPE_CONFIG,"lz4")
4.retries
kafka生产者往broker发送消息的过程中，可能会因为一些瞬时的故障导致消息发送失败，比方说网络抖动或者瞬时的leader选举。这时候我们其实没必要采用消息回调的方式来处理这种异常，因为这种异常不是消息本身问题，这时候，我们可以设置让producer自己内部实现自动的重新发送，retries参数用于设置重试的次数，默认0，不进行重试。我们可以设置成一个大于0的值，推荐设置成3-5这个值。但是有两点我们必须心里有数。
1).重试可能会导致消息的重复发送，比方说由于网络的抖动，leader副本所在的broker已经将消息持久化到本地，但是由于网络抖动，broker向leader发送相应失败，这时producer以为消息发送失败，又发送了一次，导致消息重复发送，这种情况我们可以在consumer端消费消息的时候进行去重处理。
2).重试可能导致消息的乱序，我们知道producer会将消息缓存到消息累加器中，消息累加器是一个队列，如果消息重新发送会导致消息的乱序，对于这种情况，producer提供了 max.in.flight.requets.per.connection参数，我们可以将该参数设置成1，来保证某一时刻只有只能发送一个请求。
5.batch.size
producer会将发往同一个分区的消息封装进一个batch，当batch满了会发送消息，实际中可以不等batch满了就发送消息。但是如果batch太小，显然对应的消息数量就会很少，因此一次发送请求能够写入到broker端的消息数就很少，这个参数默认值是16KB，我们可以适当调大这个参数的值来提高吞吐量。
6.linger.ms
上面说到 batch.size 时，我们提到了消息没有填满 batch 也可以被发送的情况。实际上这也是 种权衡，即吞吐量与延时之间的权衡 linger.ms 数就是控制消息发送延时行为的 该参数默认值是0 ，表示消息需要被立即发送，无须关心batch 是否己被填满，大多数情况下这是合理的 毕竟我们总是希望消息被尽可能快地发送 不过这样做会拉低 producer吞吐量，毕竟 producer 发送的每次请求中包含的消息数越多producer 就越能将发送请求的开销摊薄到更多的消息上 从而提升吞吐量。
7.max.request.size
该参数用于控制producer能够发送的最大消息的大小，默认是1M，对于一些消息很大的场景，我们是需要调大该参数的。
8.request.timeout.ms
producer发送消息给broker之后，broker需要在规定的时间之内，返回结果给producer，而这个规定的时间就是request.timeout.ms,否则就会在回调函数中显示的报超时异常。这个参数的默认值是30s，一般情况下，这个参数没什么问题，但是如果遇到producer发送消息负载很大的情况30s就有可能不够，这时候需要增大这个参数的值。
标签：发送,producer,生产者,broker,Kafka,剖析,参数,消息,leader 来源： https://www.cnblogs.com/itachilearner/p/14818988.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。