有时候,少即是多。绝对正确的一种情况是依赖项。因此,Apache Kafka社区热切地等待着对ZooKeeper服务的依赖关系的删除就不足为奇了,过去ZK主要用于存储Kafka元数据(例如,有关主题和分区的信息)以及用于集群中的领导人选举。
Kafka改进建议KIP-500 (用自管理元数据仲裁替换“ ZooKeeper”)有望在许多方面改善用户的生活:
- 只需要运行一个系统Kafka,而不是两个,就可以更好地上手,并获得更好的操作经验
- 消除ZooKeeper和Kafka控制器之间元数据状态差异的可能性
- 简化配置,例如在安全性方面
- 更好的可扩展性,例如在分区数量方面;更快地执行诸如主题创建之类的操作
使用KIP-500,Kafka本身会将所有必需的元数据存储在内部Kafka主题中,并且将根据Raft协议的一种变体(用于分布式共识),在Kafka集群节点本身(的一个子集)中进行控制器的选择。删除ZooKeeper依赖关系不仅对在生产环境中运行Kafka集群非常重要,而且对于本地开发和测试而言,能够通过单个进程启动Kafka节点非常方便。
经过多年的努力,无ZK的Kafka,也称为KRaft(“ Kafka Raft元数据模式”),最近已作为Kafka 2.8的早期访问功能发布。
在无ZK的Kafka的世界中,节点有两个节点角色:controller和broker。群集中的每个节点可以具有一个或两个角色(“组合节点”)。所有控制器节点都选择活动控制器,活动控制器负责协调整个群集,而其他控制器节点则充当热备用副本。活动控制器就是是元数据主题唯一分区的领导者。
虽然对于较小的群集,预计大多数群集节点甚至所有群集节点都充当控制器,但是较大的群集中可能只有专用的仅控制器节点,例如,在总共10个节点的群集中有3个控制器节点和7个代理节点。根据KRaft自述文件,具有专用的控制器节点应提高整体稳定性,例如,broker上的内存不足错误不会影响控制器,甚至可能导致领导者连任。
尝试无ZK的Kafka
我创建了Debezium 1.6容器映像的变体,该映像将Kafka从2.7更新为Kafka 2.8,并对使用KRaft模式的入口点脚本进行了必要的更改。请注意,此更改尚未合并到上游Debezium存储库中,因此,如果您想自己尝试一下,则必须克隆我的存储库,然后自己构建容器映像,如下所示:
$ git clone git@github.com:gunnarmorling/docker-images.git |
为了在KRaft模式下使用Kafka启动映像,CLUSTER_ID必须设置环境变量,可以从新的bin / kafka-storage.sh脚本获得这个变量值。
这是Docker Compose文件中用于启动具有三个节点的Kafka集群所需的内容:
version: '2' |
;所有节点必须相同CLUSTER_ID
;每个节点必须唯一BROKER_ID
- 所有控制器节点的地址,格式为 id1@host1:port1,id2@host2:port2…
在Debezium上工作,并成为一名Kafka Connect爱好者,我还要添加Connect和Postgres数据库以进行测试(您可以在此处找到完整的Compose文件)。
开始:
$ docker-compose -f docker-compose-zkless-kafka.yaml up
想更进一步玩儿点击标题