一篇文章学会Kafka

一、Kafka概述

Kafka传统定义：Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
Kafka最新定义 ： Kafka是 一个开源的分布式事件流平台 （Event Streaming Platform），被数千家公司用于高性能数据管道、流分析、数据集成和关键任务应用。

发布/订阅：消息的发布者不会将消息直接发送给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接收感兴趣的消息

Kafka作为一个分布式的事件流平台,能够将存储其中的数据分成不同的类别,只发送给有需要的订阅者,并且数据发送后不会被消费掉,仍存在于集群中。

消息队列的解耦功能:
允许独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

上图中,Kafka集群还能够协调Flume和Hadoop的数据传输速度,即使Flume采集速度很快,但是数据放在Kafka中,慢慢等Hadoop消费就好了。

消息队列的缓冲/消峰功能:
控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况

消息队列的两种模式:

二、Kafka基础架构

（1）Producer：消息生产者，就是向 Kafka broker 发消息的客户端。
（2）Consumer：消息消费者，向 Kafka broker 取消息的客户端。
（3）Consumer Group（CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
（4）Broker：一台 Kafka 服务器就是一个 broker。一个集群由多个broker 组成。一个broker 可以容纳多个 topic。
（5）Topic：可以理解为一个队列，生产者和消费者面向的都是一个 topic。
（6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。
（7）Replica：副本。一个 topic 的每个分区都有若干个副本，一个 Leader 和若干个
Follower。
（8）Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 Leader。
（9）Follower：每个分区多个副本中的“从”，实时从 Leader 中同步数据，保持和Leader 数据的同步。Leader 发生故障时，某个 Follower 会成为新的 Leader。

三、Kafka快速入门

1.Topic操作命令

查看主题命令参数:
[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh

参数	描述
–bootstrap-server <String: server toconnect to>	连接的 Kafka Broker 主机名称和端口号。
–topic <String: topic>	操作的 topic 名称。
–create	创建主题。
–delete	删除主题。
–alter	修改主题。
–list	查看所有主题。
–describe	查看主题详细描述。
–partitions <Integer: # of partitions>	设置分区数。
–replication-factor<Integer: replication factor>	设置分区副本。
–config <String: name=value>	更新系统默认的配置。

查看当前服务器中的所有 topic

[atguigu@hadoop102 kafka]$ 
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --list

创建 first topic

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh 
--bootstrap-server hadoop102:9092 
--create --partitions 1 --replication-factor 3 --topic first

选项说明：
–topic 定义 topic 名
–replication-factor 定义副本数
–partitions 定义分区数

查看first主题详情

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh 
--bootstrap-server hadoop102:9092 --describe --topic first

修改分区数

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh 
--bootstrap-server hadoop102:9092 --alter --topic first --partitions 3

分区数只能增加不能减少,原因是一个consumer只能消费一个分区数据,如果分区合并,消费者之间将产生冲突。

删除 topic

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh 
--bootstrap-server hadoop102:9092 --delete --topic first

2.Producer操作命令

查看生产者命令参数:
[atguigu@hadoop102 kafka]$ bin/kafka-console-producer.sh

参数	描述
–bootstrap-server <String: server toconnect to>	连接的 Kafka Broker 主机名称和端口号。
–topic <String: topic>	操作的 topic 名称。

连接first主题并发送数据

[atguigu@hadoop102 kafka]$ bin/kafka-console-producer.sh 
--bootstrap-server hadoop102:9092 --topic first
>hello world

3.consumer操作命令

查看消费者命令参数:
[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh

参数	描述
–bootstrap-server <String: server toconnect to>	连接的 Kafka Broker 主机名称和端口号。
–topic <String: topic>	操作的 topic 名称。
–from-beginning	从头开始消费。
–group <String: consumer group id>	指定消费者组名称

消费 first 主题中的数据。

[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh 
--bootstrap-server hadoop102:9092 --topic first

把主题中所有的数据都读取出来（包括历史数据）。

[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh 
--bootstrap-server hadoop102:9092 (--from-beginning) --topic first

四、Kafka生产者

在消息发送的过程中，涉及到了两个线程——main 线程和 Sender 线程。

在 main 线程中创建了一个双端队列 RecordAccumulator。main 线程将消息发送给 RecordAccumulator，Sender 线程不断从 RecordAccumulator 中拉取消息发送到 Kafka Broker。

Kafka能够通过生产者绑定自定义的分区器,拦截器完成一些自定义规则,将数据发往指定的分区。

参数名称	描述
bootstrap.servers	生产者连接集群所需的 broker 地 址 清 单 。 例 如hadoop102:9092,hadoop103:9092,hadoop104:9092，可以设置 1 个或者多个，中间用逗号隔开。注意这里并非需要所有的 broker 地址，因为生产者从给定的 broker里查找到其他 broker 信息。
key.serializer 和 value.serializer	指定发送消息的 key 和 value 的序列化类型。一定要写全类名。
buffer.memory	RecordAccumulator 缓冲区总大小，默认 32m。
batch.size	缓冲区一批数据最大值，默认 16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加。
linger.ms	如果数据迟迟未达到 batch.size，sender 等待 linger.time之后就会发送数据。单位 ms，默认值是 0ms，表示没有延迟。生产环境建议该值大小为 5-100ms 之间。
acks	0:生产者发送过来的数据，不需要等数据落盘应答。1：生产者发送过来的数据，Leader 收到数据后应答。-1（all）：生产者发送过来的数据，Leader+和 isr 队列里面的所有节点收齐数据后应答。默认值是-1，-1 和all 是等价的。
max.in.flight.requests.per.connection	允许最多没有返回 ack 的次数，默认为 5，开启幂等性要保证该值是 1-5 的数字。
retries	当消息发送出现错误的时候，系统会重发消息。retries表示重试次数。默认是 int 最大值，2147483647。如果设置了重试，还想保证消息的有序性，需要设置MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1否则在重试此失败消息的时候，其他的消息可能发送成功了。
retry.backoff.ms	两次重试之间的时间间隔，默认是 100ms。
enable.idempotence	是否开启幂等性，默认 true，开启幂等性。
compression.type	生产者发送的所有数据的压缩方式。默认是 none，也就是不压缩。支持压缩类型：none、gzip、snappy、lz4 和 zstd。

1.生产者分区

数据分区规则(分区器Parttitioner)

2.ACK数据应答

acks=0，生产者发送过来数据就不管了，可靠性差，效率高；
acks=1，生产者发送过来数据Leader应答，可靠性中等，效率中等；
acks=-1，生产者发送过来数据Leader和ISR队列里面所有Follwer应答，可靠性高，效率低；

Leader维护了一个动态的in-sync replica set (ISR),意为Leader保持同步的Follower和Leader集合(leader:0,isr:0,1,2)
如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。
该时间阈值由replica.lag.time.max.ms参数设定，默认30s。例如2超时，(leader:0, isr:0,1)。

如果分区副本设置为1个，或者ISR里应答的最小副本数量（ min.insync.replicas 默认为1）
设置为1，和ack=1的效果是一样的，仍然有丢数的风险（leader：0，isr:0）。

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

数据完全可靠条件(至少一次) = ACK=-1 + 分区副本>=2 + ISR里应答的最小副本数量>=2
最多一次(At Most Once)=ACK=0

acks=-1的时候,仍存在数据发送到broker后,leader在还没有应答的时候挂掉; 生产者没有收到回应,会再次发送数据,这将造成数据的重复。

3.幂等性和事务性

幂等性就是指Producer不论向Broker发送多少次重复数据，Broker端都只会持久化一条，保证了不重复。

精确一次(Exactly Once) = 幂等性 + 至少一次 (ack=-1 + 分区副本数>=2 + ISR最小副本数量>=2) 。

每个新的生产者实例再初始化的时候都会被分配一个PID, 这个PID对用户而言完全透明的。 对于每个PID, 消息发送到的每一个分区都有对应的序列号，这些序列号从0开始单调递增。 生产者每发送一条消息就会将<PID,分区>对应的序列号的值加1；

重复数据的判断标准：具有<PID, Partition, SeqNumber>相同主键的消息提交时，Broker只会持久化一条。
即使先后写入两条一模一样的数据，kafka也会因为Seq视为两条不同的数据，开启幂等性后，只有两条按键分区的数据其键值相同时，才会只记录第一条，忽略第二条。

PID是Kafka每次重启都会分配一个新的(Producer ID)；
Partition 表示分区号；
Sequence Number是单调自增的。所以幂等性只能保证的是在单分区单会话内不重复。
开启参数 enable.idempotence 默认为 true，false 关闭。

对于收到的每一条消息，只有当它的序列号的值（SN_new)比broker端中维护的对应序列号的值（SN_old)大1（即SN_new =SN_old+1)时，broker才会接收它。 如果SN_new < SN_old+1, 那么说明消息被重复写入，broker可以直接将其丢弃。

如果SN_new > SN_old+1,那么说明中间有数据尚未写入，出现了乱序，暗示可能有消息丢失，对应的生产者会抛出异常

事务流程:

幂等性并不能跨多个分区运行，而事务可以弥补这个缺陷。事务可以保证对多个分区写入操作的原子性。操作的原子性是指多个操作要么全部成功，要么全部失败，不存在不一致的情况。

为了实现事务,应用程序必须提供唯一的transactionalid并且开启幂等性。

Producer在使用事务之前,必须先定义一个transactionID
Kafka 有个特殊的事务 topic，名称为__transaction_state ，负责持久化事务消息
Transaction Coordinator 运行在 Kafka 服务端，简称 TC 服务。

Kafka事务使用两阶段提交协议的方式:
准备阶段
1.Producer 会首先从 Kafka 集群中选择一台机器，向其发送请求，获取本次事务协调器的地址。

2.事务的实现依赖幂等性,Producer在启动事务前，需要向协调器申请producer id。分配
producer id 后，会将它持久化到事务 topic。

3.Producer 接收到 producer id 后，就可以正常的发送消息。不过发送消息之前，需要先将这些消息的分区地址，上传到 TC 服务。TC 服务会将这些分区地址持久化到事务 topic。然后 Producer 才会真正的发送消息，这些消息与普通消息不同，它们会有一个字段，表示自身是事务消息。

这里的发送消息并不是直接发送到对应的分区中，而是将数据发送到对应的事务Topic中，并且这些数据需要携带分区地址信息。

4.Producer 发送完消息后，如果认为该事务可以提交了，就会发送提交请求到 TC 服务。Producer 的工作至此就完成了，接下来它只需要等待响应。这里需要强调下，Producer 会在发送事务提交请求之前，会等待之前所有的请求都已经发送并且响应成功。

5.TC 服务收到事务提交请求后，会先将提交信息先持久化到事务 topic 。持久化成功后，服务端就立即发送成功响应给 Producer。然后找到该事务涉及到的所有分区，为每个分区生成提交请求，存到队列里等待发送。(如果 TC 服务在发送响应给 Producer 后，还没来及向分区发送请求就挂掉了，那么 Kafka 是如何保证事务完成。因为每次事务的信息都会持久化，所以 TC 服务挂掉重新启动后，会先从事务 topic 加载事务信息，如果发现只有事务提交信息，却没有后来的事务完成信息，说明存在事务结果信息没有提交到分区。)

Produce发送数据完成提交Commit请求后，Produce工作就已经完成；
TC服务收到Commit请求后，将其持久化，证明这些数据已经被提交；
收到Commit请求后，事务Topic就可以将其存储的携带有分区信息的数据发送到对应分区；

6.后台线程会不停的从队列里，拉取请求并且发送到分区。当一个分区收到事务结果消息后，会将结果保存到分区里，并且返回成功响应到 TC服务。当 TC 服务收到所有分区的成功响应后，会持久化一条事务完成的消息到事务 topic。至此，一个完整的事务流程就完成了。

只有所有的分区都响应成狗后，本次事务才算完成，否者事务Topic中只有事务提交信息没有事务完成信息，需要回滚。

五、Kafka Broker

Broker总体工作流程

参数名称	描述
replica.lag.time.max.ms	ISR 中，如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值，默认 30s。
auto.leader.rebalance.enable	默认是 true。 自动 Leader Partition 平衡。
leader.imbalance.per.broker.percentage	默认是 10%。每个 broker 允许的不平衡的 leader的比率。如果每个 broker 超过了这个值，控制器会触发 leader 的平衡。
leader.imbalance.check.interval.seconds	默认值 300 秒。检查 leader 负载是否平衡的间隔时间。
log.segment.bytes	Kafka 中 log 日志是分成一块块存储的，此配置是指 log 日志划分 成块的大小，默认值 1G。
log.index.interval.bytes	默认 4kb，kafka 里面每当写入了 4kb 大小的日志（.log），然后就往 index 文件里面记录一个索引。
log.retention.hours	Kafka 中数据保存的时间，默认 7 天。
log.retention.minutes	Kafka 中数据保存的时间，分钟级别，默认关闭。
log.retention.ms	Kafka 中数据保存的时间，毫秒级别，默认关闭。
log.retention.check.interval.ms	检查数据是否保存超时的间隔，默认是 5 分钟。
log.retention.bytes	默认等于-1，表示无穷大。超过设置的所有日志总大小，删除最早的 segment。
log.cleanup.policy	默认是 delete，表示所有数据启用删除策略；如果设置值为 compact，表示所有数据启用压缩策略。
num.io.threads	默认是 8。负责写磁盘的线程数。整个参数值要占总核数的 50%。
num.replica.fetchers	副本拉取线程数，这个参数占总核数的 50%的 1/3
num.network.threads	默认是 3。数据传输线程数，这个参数占总核数的50%的 2/3 。
log.flush.interval.messages	强制页缓存刷写到磁盘的条数，默认是 long 的最大值，9223372036854775807。一般不建议修改，交给系统自己管理。
log.flush.interval.ms	每隔多久，刷数据到磁盘，默认是 null。一般不建议修改，交给系统自己管理。

1.kafka副本基本信息

（1）Kafka 副本作用：提高数据可靠性。
（2）Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会
增加磁盘存储空间，增加网络上数据传输，降低效率。
（3）Kafka 中副本分为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，
然后 Follower 找 Leader 进行同步数据。
（4）Kafka 分区中的所有副本统称为 AR（Assigned Repllicas）。AR = ISR + OSR

ISR，表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送
通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms
参数设定，默认 30s。Leader 发生故障之后，就会从 ISR 中选举新的 Leader。

OSR，表示 Follower 与 Leader 副本同步时，延迟过多的副本。

Leader和Follower故障问题

Follower故障处理

Leader故障处理

Leader Partition负载均衡

正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。

参数名称	描述
auto.leader.rebalance.enable	默认是 true。 自动 Leader Partition 平衡。生产环境中，leader 重选举的代价比较大，可能会带来性能影响，建议设置为 false 关闭。
leader.imbalance.per.broker.percentage	默认是 10%。每个 broker 允许的不平衡的 leader的比率。如果每个 broker 超过了这个值，控制器会触发 leader 的平衡。
leader.imbalance.check.interval.seconds	默认值 300 秒。检查 leader 负载是否平衡的间隔时间。

2.文件存储机制

Topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是Producer生产的数据**。Producer生产的数据会被不断追加到该log文件末端**，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition(log)分为多个segment。

每个segment包括：“.index”文件、“.log”文件和.timeindex等文件。这些文件位于一个文件夹下，该文件夹(log文件夹)的命名规则为：topic名称+分区序号，例如：first-0。

为了方便检索,每个Segment文件也有命名规则:

主题-分区号-文件中第一条消息的偏移量（offset）-文件中最后一条消息的偏移量+1

通过目标offset找到对应Segment文件,
查找.index稀疏索引(每个6kb记录一次索引)文件,
找到对应offset在log文件中的位置。（该log是Segment文件中的log）

说明：日志存储参数配置

参数	描述
log.segment.bytes	Kafka 中 log 日志是分成一块块存储的，此配置是指 log 日志划分成块的大小，默认值 1G。
log.index.interval.bytes	默认 4kb，kafka 里面每当写入了 4kb 大小的日志（.log），然后就往 index 文件里面记录一个索引。 稀疏索引。

文件清理策略

Kafka 中默认的日志保存时间为 7 天，可以通过调整如下参数修改保存时间。

1. log.retention.hours，最低优先级小时，默认 7 天。
2. log.retention.minutes，分钟。
3. log.retention.ms，最高优先级毫秒。
4. log.retention.check.interval.ms，负责设置检查周期，默认 5 分钟。

那么日志一旦超过了设置的时间，怎么处理呢？
Kafka 中提供的日志清理策略有 delete 和 compact 两种。
1）delete 日志删除：将过期数据删除
log.cleanup.policy = delete 所有数据启用删除策略
基于时间：默认打开。以 segment 中所有记录中的最大时间戳作为该文件时间戳。
基于大小：默认关闭。超过设置的所有日志总大小，删除最早的 segment。
log.retention.bytes，默认等于-1，表示无穷大

默认按照segment中所有记录的最大时间戳为标准。
2）compact 日志压缩:

高效读写数据

1）Kafka 本身是分布式集群，可以采用分区技术，并行度高
2）读数据采用稀疏索引，可以快速定位要消费的数据
3）顺序写磁盘
Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端，
为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这
与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

参数	描述
log.flush.interval.messages	强制页缓存刷写到磁盘的条数，默认是 long 的最大值，9223372036854775807。一般不建议修改，交给系统自己管理。
log.flush.interval.ms	每隔多久，刷数据到磁盘，默认是 null。一般不建议修改，交给系统自己管理。

页缓存是Linux内核中的一种重要的高速磁盘缓存，是计算机随机存取器RAM(内核缓存)中的一块区域，主要是负责用户空间与磁盘文件之间的高效读写。

零拷贝是一种为了解决数据从内核缓存到用户缓存的CPU拷贝产生的性能消耗的技术。
原理：当数据从磁盘经过DMA copy到页缓存（内核缓存）后，为了减少CPU拷贝的性能损耗，操作系统会将该内核缓存与用户层进行共享，减少一次CPU copy过程，同时用户层的读写也会直接访问该共享存储，本身由用户层到Socket缓存的数据拷贝过程也变成了从 内核到内核的CPU拷贝过程，更加的快速。

六、Kafka 消费者

1.消费方式具体流程

消费者总体工作流程

offset:数据偏移量,Kafka将数据存储在磁盘中,消费者在消费数据过程中宕掉也能通过存储在系统主题的offset进行再次续读。

Consumer Group（CG）：消费者组，由多个consumer组成。形成一个消费者组的条件，是所有消费者的groupid(每个消费者都会有,系统会默认分配)相同。
• 消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费。
• 消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

消费者组初始化流程

消费者组详细消费流程

参数名称	描述
bootstrap.servers	向 Kafka 集群建立初始连接用到的 host/port 列表。
key.deserializer 和value.deserializer	指定接收消息的 key 和 value 的反序列化类型。一定要写全类名。
group.id	标记消费者所属的消费者组。
enable.auto.commit	默认值为 true，消费者会自动周期性地向服务器提交偏移量。
auto.commit.interval.ms	如果设置了 enable.auto.commit 的值为 true， 则该值定义了消费者偏移量向 Kafka 提交的频率，默认 5s。
auto.offset.reset	当 Kafka 中没有初始偏移量或当前偏移量在服务器中不存在（如，数据被删除了），该如何处理？ earliest：自动重置偏移量到最早的偏移量。 latest：默认，自动重置偏移量为最新的偏移量。 none：如果消费组原来的（previous）偏移量不存在，则向消费者抛异常。 anything：向消费者抛异常。
offsets.topic.num.partitions	__consumer_offsets 的分区数，默认是 50 个分区。
heartbeat.interval.ms	Kafka 消费者和 coordinator 之间的心跳时间，默认 3s。该条目的值必须小于 session.timeout.ms ，也不应该高于session.timeout.ms 的 1/3。
session.timeout.ms	Kafka 消费者和 coordinator 之间连接超时时间，默认 45s。超过该值，该消费者被移除，消费者组执行再平衡。

2.分区分配策略

Kafka有四种主流的分区分配策略： Range、RoundRobin、Sticky、CooperativeSticky。可以通过配置参数partition.assignment.strategy，修改分区的分配策略。默认策略是Range +CooperativeSticky。Kafka可以同时使用多个分区分配策略.

Range分区策略

当coordinate检测到有消费者挂掉后,会重新按照range分区策略进行再平衡。

RoundRobin分区策略

Sticky分区策略
粘性分区定义：可以理解为分配的结果带有“粘性的”。即在执行一次新的分配之前，考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。粘性分区是 Kafka 从 0.11.x 版本开始引入这种分配策略，首先会尽量均衡的放置分区到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化。
例如:
（1）停止掉 0 号消费者，快速重新发送消息观看结果（45s 以内，越快越好）。
1 号消费者：消费到 2、5、3 号分区数据。
2 号消费者：消费到 4、6 号分区数据。

0 号消费者的任务会按照粘性规则，尽可能均衡的随机分成 0 和 1 号分区数据，分别由 1 号消费者或者 2 号消费者消费。
说明：0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。

（2）再次重新发送消息观看结果（45s 以后）。
1 号消费者：消费到 2、3、5 号分区数据。
2 号消费者：消费到 0、1、4、6 号分区数据。
说明：消费者 0 已经被踢出消费者组，所以重新按照粘性方式分配

3.Offset位移

__consumer_offsets 主题里面采用 key 和 value 的方式存储数据。key 是 group.id+topic+分区号，value 就是当前 offset 的值。每隔一段时间，kafka 内部会对这个 topic 进行compact，也就是每个 group.id+topic+分区号就保留最新数据。
offset自动提交:
为了使我们能够专注于自己的业务逻辑，Kafka提供了自动提交offset的功能。
5s
自动提交offset的相关参数：
enable.auto.commit：是否开启自动提交offset功能，默认是true
auto.commit.interval.ms：自动提交offset的时间间隔，默认是5s

offset手动提交

虽然自动提交offset十分简单便利，但由于其是基于时间提交的，开发人员难以把握offset提交的时机。因此Kafka还提供了手动提交offset的API。手动提交offset的方法有两种：分别是commitSync（同步提交）和commitAsync（异步提交）。
两者的相同点是，都会将本次提交的一批数据最高的偏移量提交；
不同点是，同步提交阻塞当前线程，一直到提交成功，并且会自动失败重试（由不可控因素导致，也会出现提交失败）；而异步提交则没有失败重试机制，故有可能提交失败。

• commitSync（同步提交）：必须等待offset提交完毕，再去消费下一批数据。
• commitAsync（异步提交） ：发送完提交offset请求后，就开始消费下一批数据了。

指定offset消费
auto.offset.reset = earliest | latest | none 默认是 latest。
当 Kafka 中没有初始偏移量（消费者组第一次消费）或服务器上不再存在当前偏移量时（例如该数据已被删除），该怎么办？
（1）earliest：自动将偏移量重置为最早的偏移量，–from-beginning。
（2）latest（默认值）：自动将偏移量重置为最新偏移量。
（3）none：如果未找到消费者组的先前偏移量，则向消费者抛出异常。
其他的offset消费方式:
（4）任意指定 offset 位移开始消费
（5）任意指定时间 offset 开始消费

重复消费：已经消费了数据，但是 offset 没提交。
漏消费：先提交 offset 后消费，有可能会造成数据的漏消费。

想要保证数据的精确性,需要事务的支持,需要下游消费者能够提供事务技术。

4.数据积压

大量数据的积压,Kafka消费能力不足,不能够在数据失效之前消费完数据。

参数名称	描述
fetch.max.bytes	默认 Default: 52428800（50 m）。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值（50m）仍然可以拉取回来这批数据，因此，这不是一个绝对最大值。一批次的大小受message.max.bytes （broker config）or max.message.bytes （topic config）影响。
max.poll.records	一次 poll 拉取数据返回消息的最大条数，默认是 500 条