kafka进阶-文末思维导图

kafka的第二篇，文末依旧是思维导图。

消费者组重平衡

弊端

影响Consumser端TPS

慢，效率低

发生时机

组成员数据发生变化

订阅主题数量发生变化

订阅主题分区数发生变化

优化配置，避免不必要的Rebalance

尝试解决：Consumer没能及时发送心跳请求，导致被踢出Group

session.timeout.ms 会话间隔

heartbeat.interval.ms 心跳间隔

session.timeout.ms >= 3* heartbeat.interval.ms 至少3轮的心跳请求。

尝试解决：Consumer 消费时间过长导致的

max.poll.interval.ms拉取消息的时间间隔

发生Rebalance时，由哪个线程通知其他消费者实例

0.10.1.0版本之前，在消费者主线程中

目前心跳线程，heartbeat.interval.ms 控制重平衡通知的频率

消费者组状态机

协调者端处理重平衡

协调者组件保存着当前向他注册过的所有组信息。

场景

新成员入组

组成员主动离组

组成员崩溃离组

重平衡时协调者对组内成员提交位移的处理

步骤

当重平衡开启时，协调者会给予成员一段缓冲时间，要求每个成员必须在这段时间内快速地上报自己的位移信息

然后再开启正常的 JoinGroup/SyncGroup 请求发送

重平衡流程

JoinGroup请求 和 SyncGroup请求。

第一个发送JoinGroup的成为领导者

领导者(消费者)，收集所有成员的订阅信息，然后根据这些信息，指定具体的分区消费方案

无消息丢失配置

生产者部分

使用producer.send(msg,callback) callback 可以准确知道消息是否提交成功。

设置acks=all 所有副本都接收到消息。

设置retries为一个较大的值 重试防止网络抖动。

Broker部分

unclean.leader.election.enable=false , Broker端参数，禁止落后的Broker成为Leader。

replication.factor>=3, Broker端的参数 , 副本数量，冗余。防止消息丢失。

min.insync.replicas>1, Broker端的参数 , 至少要写入的最小副本数，提升消息持久性。

确保replication.factor > min.insync.replicas 副本数大于最小写入副本数，否则有一个副本挂了，集群就不可用了。

建议：replication.factor = min.insync.replicas + 1

消费者部分

确保消息消费完成再提交点位

副本机制

什么是副本

通常是分布式系统再多台网络互联的机器上保存有相同的数据拷贝。

好处

提供数据冗余 （kafka仅仅用到这个好处）

提高伸缩性

改善数据局部性

Kafka追随者副本不对外提供服务的原因

方便实现 Read-your-writes ，向Kafka成功写入消息后，马上使用消费者API去读取刚才生成的消息

方便实现单调读

In-sync Replicas (ISR)

同步副本集，包含Leader 与follower副本

判断Follower与Leader同步的标准

replica.lag.time.max.ms参数值，Follwer副本能落后Leader副本的最长时间间隔，默认为10s

拦截器

基本思想

不修改应用程序的逻辑的情况下，动态的实现一组可插拔的事件处理逻辑链。

使用场景

端到端系统性能检查、消息审计等多种功能在内的场景。

拦截点

生产者拦截器

发送消息前

消息提交成功后

消费者拦截器

消费消息前

提交位移后

注意事项

指定拦截器类时，一定要指定它们的全定限名