Kafka的zookeeper依赖演进
clients对zk的依赖
从0.8.x版本到0.11.x版本，clients端已经基本移除对zk的依赖：
- consumer端位移操作与位移主题直接交互，consumer group交给Coordinator管理
- Admin client创建删除主题操作
目前Kafka对ZooKeeper的依赖包括：
- broker存活
- controller选举
- 元数据管理
目前zk保存的元数据有：
移除的原因
- 虽然元数据更新是同步写入ZooKeeper的，但是异步发送给broker的。此外，从ZooKeeper接收更新也是异步的。所有这些都有可能导致broker、控制器和ZooKeeper之间的元数据出现不一致。一旦出现这些情况，将很难检测到。
- 控制器在重新启动时需要从ZooKeeper读取所有的broker和分区的元数据，然后再将它们发送给所有的broker。尽管经过了多年的努力，这个过程仍然是一个主要瓶颈——随着分区和broker数量的增加，重启控制器的速度将会更慢。
- 元数据所有权关系的内部架构不够好——有些操作是通过控制器完成的，有些操作是通过broker完成的，还有一些操作是直接通过修改ZooKeeper完成的。
- 与Kafka一样，ZooKeeper本身就是一个分布式系统，要求开发者具备一定的专业知识。因此，想要用好Kafka的开发者需要了解两个分布式系统，而不是一个。
移除的方案
Metadata as an Event Log
将元数据作为 Log 的方式保存起来，有以下几个优点:
- 高可用性：每次元数据的变更都被当作是一条消息保存在 Log 中，而这个 Log 可以被视为一个普通的
Kafka 主题被备份到多台 Broker 上。 - 顺序性：Log 的一个好处在于它有清晰的前后顺序关系，配合以恰当的处理逻辑，我们就能保证，对元数据变更的处理是按照变更发生的时间进行顺序处理的，不出现乱序的情形。
- 增量同步性：利用 Log 机制之后，Broker 间同步元数据能够采用
同步增量数据（delta）的方式，无需每次都同步全量数据。目前，Kafka Broker 间同步元数据都是全量状态同步的。前面说过了，当集群分区数很大时，这个开销是很可观的。如果我们能够只同步增量状态，势必能极大地降低同步成本。 - 可监控性：Log 提供了丰富的监控指标。我们根据这些指标能够轻易地获取到元数据同步的进度。
Controller Quorum
整个 Controller quorum 类似于一个小的集群。和 ZooKeeper 类似，这个 quorum 通常是 3 台或 5 台机器，不需要让 Kafka 中的每个 Broker 都自动成为这个 quorum 中的一个节点。使用Raft选举策略选leader。有以下几个优点：
- 低延时的 Failover，因为不需要从zk中拉取元数据，所有的元数据现在都同步保存 Follower 节点的内存中，Leader 的切换会非常得迅速，它已经有其他 Broker 需要拉取的所有元数据信息了。
- 避免了Controller 切换，就要全量拉取元数据的低效行为，Broker 不需要重新拉取之前已经“消费”的元数据变更消息，只需要从新的Leader拉取增量数据即可。
现状
最新版的Kafka 2.8.0，移除了对Zookeeper的依赖，通过KRaft进行自己的集群管理。（zhuanlan.zhihu.com/p/368600560… 但是官方声称有些功能还不是太完善，所以不要把它用在线上。
总结
去除zk可以避免多维护一套zk集群，同时zk在写入多的时候比较慢。之前controller切换需要去zk拉取元数据信息，之后再同步给所有broker，去掉zk之后，controller选举不需要再拉取元数据，元数据也可以做增量同步。
参考
issues.apache.org/jira/browse…
