点击下方“JavaEdge”，选择“设为星标”
第一时间关注技术干货！
免责声明~ 任何文章不要过度深思！ 万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」； 不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。 怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」
Kafka 为什么要抛弃 ZooKeeper？取代方案是怎样的？
因为确实有优化空间。
Zookeeper加kafka 的架构，有三层角色：
zookeeper ，提供基础的状态持久化和状态通知服务
controller ，基于zookeeper提供的服务，给松散的broker提供统一的状态服务，但它本身没有状态服务，它是依赖zookeeper 的服务来做主控
一层是broker ，无状态服务，因为他们无状态，无法自发组织起来，所以需要controller为他们做主控。其中有一个broker 兼职了controller 角色
这架构本没问题，但要优化也可以。zookeeper本来提供状态服务，但它不是kafka一部分，所以kafka不得不设计一个controller做主控。假如controller本身就可提供状态服务，那三层架构就可简化成两层：
controller ，提供主控服务
broker ，无状态工作服务
Kafka 抛弃zookeeper 就是做这优化，自己开发基于raft 共识算法的一致性服务kraft：
为集群提供之前zookeeper的状态服务的同时
也为broker 提供主控服务即controller
还有很大优点，controller故障切换很快，且切换时间几乎不随集群规模而线性增长。
以前架构
controller 只有一个，如做controller故障切换，新controller需全量从zookeeper同步集群所有元数据信息并构建到内存，为做主控服务做准备，这些元数据信息包括topic和分区信息，如一个大规模集群，topic 和分区很多，该过程很耗时，也就会造成更久停机时间。
以前的架构也可以安排一些broker作为备选controller定期从zookeeper同步元数据，但这只是解决了部分问题，https://cwiki.apache.org/confluence/display/KAFKA/KIP-500:+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum。以前的架构，只有选出来的主控才会同步数据，其他没胜出的broker 只做broker 的角色。具体辩论，大家自查。
controller有多个，只是只有一个是leader 提供主控服务，其他的作为follower ，会实时同步leader的元数据信息，也就是元数据在多个controller 里面是几乎保持一致的(raft 协议保证的)，所以故障切换的时候，几乎不需要再同步元数据，就可以完成controller 切换。
官方文件解读
参照官方的KIP议案。
Colin McCabe发起提案：[KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum]
具体讨论细节参考邮件列表：https://lists.apache.org/thread/w43g74zlttpn2nl2nyppp4fsdszwg7sb
要解决问题
为啥替换zk，主要：
集群元数据的管理将更具有扩展性（scalable），更健壮（robust）
之前受zookeeper的影响，集群可以创建的[topic]数量是受限的，新的架构可以支持更多的topic。
简化Kafka的部署流程和配置成本
第一个集群状态[元数据管理]暴漏出来的问题：因为[元数据]管理（zk state）和集群状态的管理（controller state）是不同的数据管理路径，经常导致zk中的状态和集群控制器controller中的状态不一致的问题。两个数据源要进行数据状态的同步，这本身就是[分布式系统]中的一个让人头疼的事情。如果controller简单通过watch机制来监听zk的变更日志来同步状态的话，由于watch机制的限制，这个方法的性能会出问题，而且还没有考虑到watch通知机制的可靠性。
相比之前需要显示通知broker的方式，新的方式情况下，各个broker也将采取订阅 metadata event log的方式，和kafka本身要解决的问题本质上是类似的。broker本身要一个文件来存储自己维护的元数据信息。通过这种方式，kafka可以支持更多的partition数量，并且可以进一步的降低CPU的利用率。
第二个角度是从运维和配置的角度来看：
由于引入了zk这个独立的分布式组件系统，那我们的运维人员在部署kafka的时候，除了kafka本身，还需要有zk的部署运维经验。而如果把zk依赖去掉，降低了系统部署和运维的难度
去掉依赖之后，Kafka就有可能支持一个单节点的部署模式，方便大家更快的尝试Kafka。
Zookeeper在kafka生态中遇到一些问题梳理：
client 和zk的沟通问题
zk和broker沟通问题
架构变更和产品[路线图]
提案大的架构设计变动图：
新的架构图
大概的方案设计细节，大家可以参考[wiki文档]
引用：
1 KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum
2 Introducing KRaft: Kafka Without Zookeeper
Introducing KRaft: Kafka Without Zookeeper With Colin McCabe | Current 2022
3 Colin McCabe Updates on Apache Kafka KRaft Mode
Colin McCabe Updates on Apache Kafka KRaft Mode
4 Removing the Dependency of Zookeeper on Kafka
Removing the Dependency of Zookeeper on Kafka
5 Kafka Needs No Keeper
Kafka Needs No Keeper
6 Colin McCabe 在CMU的个人主页
About
7 [KIP-98 - Exactly Once Delivery and Transactional Messaging]
公众号：JavaEdge 专注分享软件开发全生态相关技术文章、视频教程资源、热点资讯等，如果喜欢我的分享，给 点一个赞 或者 ➕关注 都是对我最大的支持。
欢迎长按图片加好友，我会第一时间和你分享软件行业趋势，面试资源，学习途径等等。
添加好友备注【技术群交流】拉你进技术交流群
关注公众号后，在后台私信：
更多教程资源应有尽有，欢迎
关注，慢慢获取