Kafka之producer的执行

一、producer的执行过程

producer包含几个部分
1.初始化
2.发送流程
3.缓存区
4.IO处理

其中初始化包含以下几个阶段：
1）设置分区器
2）设置重试参数
3）设置序列化器
4）设置拦截器
5）执行累加器
6）初始化元数据（topic，partition等）
7）执行send()方法
9）启动IO Thread,运行runnable

发送过程包含以下几个阶段：
1）执行拦截器
2）序列化处理
3）分区处理
4）把消息写入缓冲区

二、producer的优化

1.发送确认的acks机制：在集群模式下，需满足acks指定的条件，才会认为消息成功写入Kafka
三种模式
1）acks=0 只要发出去，就认为消息已经写入kafka
2）acks=1 写入分区的副本 只要写入一个就返回确认
3）acks=all或者-1 全部的副本都收到了，就返回确认。其中全部的副本不是真正物理意义的全部副本，而是指 min.insync.repilcas参数的值，即 全部等价于 min.insync.repilcas
例如 一个集群共有5台brokers 当acks=all min.insync.repilcas=3 则 当同步数达到3时 返回确认

若追求性能 min.insync.replicas =1 leader同步成功返回成功 （当leader宕机 ，必然丢失数据）
min.insync.replicas =3 3个副本的服务器同步成功则返回成功，这个是集群下相对稳妥的方案

2.max.request.size默认1M 建议适当调大10M
3.retries失败重试次数 默认0 不重试，建议改为2或者3
4.compression.type 默认是没有压缩
5.Buffer.memory 缓冲区的大小 默认值是32M 建议可以调大，代价是占用客户端的内存
6.batch.size 发送到缓存冲的消息被封装成一个batch的大小，默认是16kb 建议生产时可以适当调大
7.linger.ms 发送到broker的延迟，延迟越大 发送频率越低，效率越高，但实时性越低。实际发送的触发条件取决于batch.size 和linger.ms 通过决定 （体量到达batch.size或者时间达到linger.ms后发送到broker）