分布式-MQ-06Kafka特性详解&场景介绍(二)

Kafka特性详解Q&A

1、HW、LW、LEO、ISR的含义和关系

LEO： Log end offset，Kafka 分区消息的终点，消息终止偏移，下一条消息的插入位置

HW：High water mark 高水位 用于控制消息可见性，HW 以下的消息对外可见，HW 的位置可能对应一条消息，但是对外不可见不可以消费，HW 的最大值是 LEO，分区 HW 就是 leader 副本的 HW 值=整个ISR分区所有副本的的LEO

LW：Low water mark，用于控制消息可见性，LW 及以上的消息对外可见

ISR：In sync replica 指满足副本同步要求的副本集合，包括领导者副本

2、kafka的rebalance机制 是什么？

Kafka的rebalance（重新平衡）指的是Kafka消费者组内部的一种协议和过程，用于在消费者组成员发生变化或者分区发生变化时重新分配分区所有权。这个过程确保了每个分区都由消费者组中的一个成员来消费，并且当消费者加入或离开消费者组时，或者主题的分区数发生变化时，分区的分配关系能够自动调整

3、rebalance的触发条件

1、分区数发生变化（分区只能增不能减）
2、消费者加入或者离开
3、消费者失效：如果一个消费者由于网络原因、故障或其他原因失去联系，则该消费者拥有的分区将被重新分配给其他消费者。（session 超时和 pull超时）

4、rebalance的过程

1、消费成员向coordinator发送请求加入cosummer group
2、coordinator选择一个consumer担任leader角色
3、leader分配消费方案，上报给coordinator
4、coordinator收到后同步方案给其他consumer

5、rebalance的影响

1、重复消费，原consumer踢出前还没提交offset，rebalance后部分会重新消费，可以通过幂等解决
2、临时停顿，集群不稳定
3、频繁的rebalance影响整体的消费速度

6、如何避免rebalance发生，减少rebalance的影响

1、优雅退出close消费者
2、及时提交偏移量，每一条提交一次
3、避免消费者心跳和session超时或者消费拉取超时被踢出消费者组，从而rebalance

7、比较常见的引起消费组成员的加入或离开导致rebanlance的原因

（1）未能及时发送心跳而Rebalance
session.timeout.ms 一次session的连接超时时间，heartbeat.interval.ms 心跳时间，一般为超时时间的1/3，Consumer在被判定为死亡之前，能够发送至少 3 轮的心跳请求。heartbeat.interval.ms 默认值 3000，也就是每3s发送一次心跳包。

（2）Consumer消费超时而Rebalance
每隔多长时间去拉取消息。合理设置预期值，尽量但间隔时间消费者处理完业务逻辑，否则就会被coordinator判定为死亡，踢出Consumer Group，进行Rebalance。
max.poll.records 一次从拉取出来的数据条数。根据消费业务处理耗费时长合理设置，如果max.poll.interval.ms 设置的时间较短，可以max.poll.records设置小点儿，少拉取些，这样不会超时。
总之，尽可能在max.poll.interval.ms时间间隔内处理完max.poll.records条消息，让Coordinator认为消费Consumer还活着

8、几个时间配置的定义和影响

1. request.timeout.ms
   定义：这个配置参数指定了客户端等待Kafka服务端响应的最长时间。如果请求在这个时间内没有收到响应，客户端会重试发送请求（根据重试策略）。
   影响：设置太短可能导致在正常的负载和轻微网络延迟情况下出现不必要的重试。设置太长，可能在服务端处理出现问题时，导致客户端长时间等待响应，影响客户端处理效率。
2. session.timeout.ms
   定义：这个配置参数用于控制消费者被认为是存活的最小时间间隔。如果在这个时间间隔内，消费者没有向Kafka集群发送心跳，则认为该消费者已经死亡，会从它所在的消费者组中移除。
   影响：设置太短可能导致在正常的网络波动或者处理较大消息时，消费者被误认为已经死亡。设置太长，当消费者真的失败时，Kafka集群需要更长的时间来检测到这一点，并进行重新平衡，影响消息的及时消费。
3. heartbeat.interval.ms
   定义：这个配置参数指定了消费者发送心跳给Kafka协调者的频率。心跳是用来表明消费者存活的状态、加入和退出消费者组的机制。
   影响：设置太短会导致消费者发送过多的心跳，增加Kafka集群的负载。设置太长，可能会导致Kafka协调者在session.timeout.ms时间内检测不到消费者的存活状态，导致消费者被误判为已经死亡。
4. max.poll.interval.ms
   定义：这个配置参数指定了消费者在两次调用poll()方法之间的最大时间间隔。如果超过这个时间没有调用poll()，Kafka会认为消费者已经死亡，将其从消费者组中移除，并触发重新平衡。
   影响：设置太短可能会导致在处理大批量消息、网络延迟或系统负载高的情况下，无法在时间间隔内完成poll()调用。设置太长，就像session.timeout.ms一样，影响故障检测和重新平衡的响应速度。

结论

​ 这些配置参数之间的关系非常密切，需要根据实际使用场景和Kafka集群的性能来合理设置。session.timeout.ms、heartbeat.interval.ms和max.poll.interval.ms特别关系到消费者的健康检测和消费者组的稳定性。request.timeout.ms更多的影响到客户端与服务端之间通信的效率和稳定性。合理配置这些参数可帮助保证Kafka消费者服务的高可用性和消息的及时处理。

9、kafka生产者发送消息的同步机制

（1）acks=0： 表示producer不需要等待任何broker确认收到消息的回复，就可以继续发送下一条消息。性能最高，但是最容易丢消 息。大数据统计报表场景，对性能要求很高，对数据丢失不敏感的情况可以用这种。

（2）acks=1： 至少要等待leader已经成功将数据写入本地log，但是不需要等待所有follower是否成功写入。就可以继续发送下一条消 息。这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失。

（3）acks=-1或all： 生产者需要等待 所有当前 ISR（同步副本）中的副本成功写入消息，而 ISR 的数量必须 **至少等于 min.insync.replicas**。这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的数据保证。一般除非是金融级别，或跟钱打交道的场景才会使用这种配置。当然如果 min.insync.replicas配置的是1则也可能丢消息，跟acks=1情况类似。

在分区存在副本的情况下，使用leader-follower，leader负责读写请求，follower从分区leader那复制数据

（1）、在分区存在副本的情况下，使用leader-follower，leader负责读写请求，follower从分区leader那复制数据
（2）、复制数据时：leader接收到写请求，写入到本地日志，紧接着folloer从leader获取数据并将其写入到自己的日志。
（3）、一旦超过Kafka Broker端的配置min.insync.replicas数量的ISR副本都成功复制了数据，leader则认为数据已被成功复制。
（4）、Kafka设计了复制延迟的容忍机制，如果Follower与Leader之间的复制延迟超过配置的阈值，则Follower会被认为是落后的，并可能从ISR列表中移除。

10、什么是ISR（In-Sync Replicas）

1、ISR是一组保持与Leader同步的副本列表
2、如果Follower太久没有从Leader复制数据，或者跟不上Leader的数据同步速度，它会从ISR中移除。
3、ISR确保只有那些与Leader保持同步的副本才能被选举为Leader，从而确保数据不会丢失

​ replica.lag.time.max.ms：决定了一个副本被认为是落后（并可能从ISR中移除）的最大时间。如果副本在该时间内未同步数据，它会被认为是落后的。
​ min.insync.replicas：这是针对每个主题可以设置的参数，指定了一个生产者在考虑写入请求成功之前，必须有多少ISR副本确认接收到数据。

结论：kafka通过分区来提升并发度，利用分区副本和leader-follower+ISR来保障高可用性和一致性。

11、Kafka消费发布流程

1、producer先根据路由规则，把消息发送到指定partition的leader
2、leader将消息写入本地log
3、folloer从leader pull消息，写入本地log后leader发送ack
4、leader接受到一定数量的ISR中的分区副本的ack后，增加HW（hight watermark，最后后一条commit的offset ），并向producer发送ack

12、消息丢失

1、生产者->server：设置重试，重试间隔，设置ack=alls(实际采用ISR机制)
2、消费者：手动提交+消费完再提交

13、消息重复消费

1、生产者重复投递-消费者支持幂等
2、消费超时等失败场景导致重复投递：加快单条消费速度+适当调整max.poll.interval.ms和调小max.poll.records，避免消费太多无法及时poll从而触发rebalance。一般而言max.poll.interval.ms > session.timeout.ms

14、消息积压

1、增加分区，增加消费者数量
2、分析堆积原因，通过设置消费偏移量解决
3、kafka不适合长任务，避免引起重平衡，长耗时任务丢给异步任务处理
4、1个分区时，临时调整，根据需要开多个消费组处理特定逻辑
5、临时增加消息保留时间
6、评估多个分区，局部有序的方案

15、Kafka相较于其他平台比如RabbitMQ的优势，为什么支持大数据量

优点：

A、分布式架构：扩展性和可靠性

B、持久化存储：持久化在磁盘上保存一段时间，单个broker支持TB级别数据

C、高性能高吞吐：采用磁盘顺序写，比随机写效率高、支持批量发消息和消费消息、partition机制：topic分为多个分区，挺高并行度也提高吞吐量

D、leader-follow + ISR机制，保障快速写入和数据不丢失

缺点：

1、消费者数量受到分区数限制

2、不支持事务

3、运维成本高