Flink是大数据开发中常用的组件,可以用于kafka的生产者,也可用于kafka的消费者。
一、配置
kafka 生产者batch.size与linger.ms参数
Kafka需要在吞吐量和延迟之间取得平衡,可以通过下面两个参数控制.
batch.size
当多个消息发送到相同分区时,生产者会将消息打包到一起,以减少请求交互. 而不是一条条发送
批次的大小可以通过batch.size 参数设置.默认是16KB
较小的批次大小有可能降低吞吐量（批次大小为0则完全禁用批处理）。
一个非常大的批次大小可能会浪费内存。因为我们会预先分配这个资源。
例子
比如说发送消息的频率就是每秒300条，那么如果比如batch.size调节到了32KB，或者64KB，是否可以提升发送消息的整体吞吐量。
因为理论上来说，提升batch的大小，可以允许更多的数据缓冲在里面，那么一次Request发送出去的数据量就更多了，这样吞吐量可能会有所提升。
但是这个东西也不能无限的大，过于大了之后，要是数据老是缓冲在Batch里迟迟不发送出去，那么岂不是你发送消息的延迟就会很高。
比如说，一条消息进入了Batch，但是要等待5秒钟Batch才凑满了64KB，才能发送出去。那这条消息的延迟就是5秒钟。
所以需要在这里按照生产环境的发消息的速率，调节不同的Batch大小自己测试一下最终出去的吞吐量以及消息的延迟，设置一个最合理的参数。
linger.ms
上面比如我们设置batch size为32KB,但是比如有的时刻消息比较少,过了很久,比如5min也没有凑够32KB,这样延时就很大,所以需要一个参数. 再设置一个时间,到了这个时间,即使数据没达到32KB,也将这个批次发送出去. 比如设置5ms,就是到了5ms,大小没到32KB,也会发出去
总结
同时设置batch.size和 linger.ms,就是哪个条件先满足就都会将消息发送出去
Kafka需要考虑高吞吐量与延时的平衡.
buffer.memory参数
Kafka的客户端发送数据到服务器，不是来一条就发一条，而是经过缓冲的，也就是说，通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲里，然后把很多消息收集成一个一个的Batch，再发送到Broker上去的，这样性能才可能高。
buffer.memory的本质就是用来约束Kafka Producer能够使用的内存缓冲的大小的，默认值32MB。
如果buffer.memory设置的太小，可能导致的问题是：消息快速的写入内存缓冲里，但Sender线程来不及把Request发送到Kafka服务器，会造成内存缓冲很快就被写满。而一旦被写满，就会阻塞用户线程，不让继续往Kafka写消息了。
所以“buffer.memory”参数需要结合实际业务情况压测，需要测算在生产环境中用户线程会以每秒多少消息的频率来写入内存缓冲。经过压测，调试出来一个合理值。
Kafka的认证机制
概述：
- GSSAPI：使用的Kerberos认证，可以集成目录服务，比如AD。Kafka最小版本 0.9
- PLAIN：使用简单用户名和密码形式，Kafka最小版本 0.10
- SCRAM：主要解决PLAIN动态更新问题以及安全机制，Kafka最小版本 0.10.2
- OAUTHBEARER：基于OAuth 2认证框架，Kafka最小版本 2.0
配置SASL\PLAIN
创建kafka_server_jaas.conf文件
并行度
如果设置的并行度>数据条数，后面输出结果数值则不会重复。
如果设置的并行度<数据条数，后面输出结果数值则会重复。
1 flink consumer kafka数据
mod(kafka partiton) % (flink 并行度)
1.1 kafka = flink 并行度
一对一的关系
1.2 kafka > flink
flink 每个并行度会可能消费多个kafka分区数据
1.3 kafka < flink
flink 某个并行度肯定会没有数据消费
