kafka02-分区策略-提高吞吐量-数据可靠性-数据重复问题

在创建topic主题时，必须指定分区数和副本数，否则无法创建成功！

生产者send数据时的分区策略：

1. 指定分区：将数据直接写入指定分区

2. 没有指定分区，但有key： 取key的hash值与partition数 取余 得到的值便是 存入的分区

3. 没有指定分区，也没有key，只有value：随机选择一个分区，直到该分区batch达到16k满了，或linger.ms时间到了，便会重新随机选择一个分区（不会使用已使用过的分区）

4. 可以自定义分区策略，实现Partitioner，通过自己的业务逻辑判断来指定分区

 

 

生产者如何提高吞吐量：

producer properties指定连接kafka集群，设置序列化后，对以下四个参数做设置，来提高吞吐量：

1. batch.size：批次大小，默认16k -> 生产环境一般会改为32k

2. linger.ms：等待时间，默认为0ms -> 生产环境一般会改为5-100ms

3. compression.type：压缩snappy (压缩类型有：gzip、snappy、lz4、zstd)

4. RecordAccumulator：缓冲区大小，默认32M -> 生产环境一般会改为64M

数据的可靠性：

我们知道，kafka应答机制ack分为0，1，-1

0 只发送，不需要应答。效率高，但可靠性差。问题：无法保证数据是否真实被接收

1 leader收到应答。效率中等，可靠性中等。问题：提升了可靠性，但如果leader挂了，follower没能及时同步，数据丢失

-1 leader和ISR队列里所有follwer都收到后应答。效率低，可靠性高。问题：响应速度降低，速度慢，同时如果其中一个follow异常，一直无法同步数据，就会导致一直无法应答。解决方式：leader维护了一个动态集合（in-sync replica set = ISR），里面维护了leader和活跃的follwer，如果某个floower在一定时间内没有响应，则会被剔除（默认30s）

在生产环境中，acks=0很少使用；acks=1一般用户传输普通日志；acks=-1一般用于传输和钱相关的数据，对可靠性要求相对高的场景。

 

 

 

 

数据重复问题：

除了acks=0时不会存在数据重复问题意外，1和-1都会有数据重复的可能，而-1的可能性最大。例如：当生产者发送数据给kafka，在leader和所有follwer都接收处理完毕，在应答前，leader突然宕机了，应答失败后sender线程会尝试重新推送数据，此时就会造成数据重复。

解决方案：幂等性（见下图）：默认是开启的。原理：producer这边随便发数据，幂等性主要是在kafka broker leader上做处理，以PID,Protition和SeqNumber为一组条件，如果相同，则判定为重复数据。

PID：每次kafka重启时都会生成一个（会话ID）

SeqNumber：序列化ID号

Partition ： 分区

由于幂等性只能保证单分区单会话内不重复，所以需要事务来处理

 

 

 

 

事务：事务依赖于幂等性，注意：在使用事务时，必须指定一个唯一的事务ID

 

 

数据有序：

1. 同一分区内保证有序

2. 不同分区内保证有序（会有一个专门排序的队列，将多区数据整合后进行排序。缺点：需要等多区数据都推送完成后才能处理，效率低）

数据乱序：