1.线上问题rebalance
因集群架构变动导致的消费组内重平衡，如果kafka集内节点较多，比如数百个，那重平衡可能会耗时导致数分钟到数小时，此时kafka基本处于不可用状态，对kafka的TPS影响极大
产生的原因
①组成员数量发生变化
②订阅主题数量发生变化
③订阅主题的分区数发生变化
组成员崩溃和组成员主动离开是两个不同的场景。因为在崩溃时成员并不会主动地告知coordinator此事，coordinator有可能需要一个完整的session.timeout周期(心跳周期)才能检测到这种崩溃，这必然会造成consumer的滞后。可以说离开组是主动地发起rebalance；而崩溃则是被动地发起rebalance。
解决方案
加大超时时间 session.timout.ms=6s
加大心跳频率 heartbeat.interval.ms=2s
增长推送间隔 max.poll.interval.ms=t+1 minutes
2.Zookeeper的作用
目前，Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务。之后，等 KIP-500 提案完成后，Kafka 将完全不再依赖于 ZooKeeper。
●存放元数据是指主题分区的所有数据都保存在 ZooKeeper 中，其他“人”都要与它保持对齐。
●成员管理是指 Broker 节点的注册、注销以及属性变更等 。
●Controller 选举是指选举集群 Controller，包括但不限于主题删除、参数配置等。
一言以蔽之:KIP-500 ，是使用社区自研的基于 Raft 的共识算法，实现 Controller 自选举。
同样是存储元数据，这几年基于Raft算法的etcd认可度越来越高
越来越多的系统开始用它保存关键数据。比如，秒杀系统经常用它保存各节点信息，以便控制消费 MQ 的服务数量。还有些业务系统的配置数据，也会通过 etcd 实时同步给业务系统的各节点，比如，秒杀管理后台会使用 etcd 将秒杀活动的配置数据实时同步给秒杀 API 服务各节点。
3.Replica副本的作用
Kafka 只有 Leader 副本才能 对外提供读写服务，响应 Clients 端的请求。Follower 副本只是采用拉(PULL)的方 式，被动地同步 Leader 副本中的数据，并且在 Leader 副本所在的 Broker 宕机后，随时准备应聘 Leader 副本。
●自 Kafka 2.4 版本开始，社区可以通过配置参数，允许 Follower 副本有限度地提供读服务。
●之前确保一致性的主要手段是高水位机制， 但高水位值无法保证 Leader 连续变更场景下的数据一致性，因此，社区引入了 Leader Epoch 机制，来修复高水位值的弊端。
4.为什么不支持读写分离
●自 Kafka 2.4 之后，Kafka 提供了有限度的读写分离。
●场景不适用。读写分离适用于那种读负载很大，而写操作相对不频繁的场景。
●同步机制。Kafka 采用 PULL 方式实现 Follower 的同步，同时复制延迟较大。
5.如何防止重复消费
●代码层面每次消费需提交offset
●通过Mysql的唯一键约束，结合Redis查看id是否被消费，存Redis可以直接使用set方法
●量大且允许误判的情况下，使用布隆过滤器也可以
6.如何保证数据不会丢失
●生产者生产消息可以通过comfirm配置ack=all解决
●Broker同步过程中leader宕机可以通过配置ISR副本+重试解决
●消费者丢失可以关闭自动提交offset功能，系统处理完成时提交offset
