江苏龙网

  1. 首页 > 人文 > >

Kafka自维护计划：删除ZooKeeper依赖关系( 二 )


KIP-500将加快主题的创建和删除 。 现在创建或删除主题时 ， 控制器必须从ZooKeeper重新加载集群中所有主题名称的完整列表 。 这是必须的 ， 因为当集群中的主题集发生更改时 ， 当ZooKeeper通知我们时 ， 它并不能告诉我们确切地添加或删除了哪些主题 。 相反 ， 在KIP-500中创建或删除主题将仅涉及在元数据分区中创建新条目 ， 这是个O(1)操作 。
元数据可伸缩性是将来扩展Kafka的关键部分 。 期望用单个Kafka集群最终将能够支持一百万个分区或更多 。
路线图
从Kafka的管理工具中删除ZooKeeper
作为Kafka版本的一部分提供的一些管理工具仍然可以和ZooKeeper直接通信 。 除了这种直接的ZooKeeper通信之外 ， 仍然无法完成一两个操作 。
很快 ， 对于以前需要直接ZooKeeper访问的每个操作 ， 将都有一个公共的Kafka API 。 在下一个主要版本的Kafka中将禁用或删除不必要的--zookeeper的标志 。
自我管理的元数据仲裁
在KIP-500中 ， Kafka控制器会将其元数据存储在Kafka分区中 ， 而不是存储在ZooKeeper中 。 但是 ， 由于控制器依赖于该分区 ， 因此分区本身不能依赖控制器来进行领导者选举之类的事情 。 而是 ， 管理该分区的节点必须实现自我管理的Raft仲裁
KIP-595：用于元数据仲裁的Raft议案提出了如何将Raft协议调整为适合Kafka的方式 ， 以使其真正感觉像系统的本机部分 。 这将涉及将Raft中描述的基于推的模型更改为基于拉的模型 ， 这与传统的Kafka复制是一致的 。 如其将数据推送到其他节点 ， 其他节点将连接到它们 。 同样 ， 将使用与Kafka一致的术语 。
最初的实现将集中在支持元数据分区上 。 它不支持将常规分区转换为Raft所需的全部操作 。
KIP-500模式
当然 ， 该项目最激动人心的部分是在 KIP-500模式下无需ZooKeeper即可运行集群的能力 。 当Kafka用该模式运行时 ， 将使用Raft仲裁存储元数据 ， 而不是ZooKeeper 。
最初 ， KIP-500模式将是实验性的 。 大多数用户将继续使用''传统模式'' ， 而ZooKeeper仍在使用中 。 部分原因是因为KIP-500模式最初并不支持所有可能的功能 。 另一个原因是希望在将其设置为默认值之前对KIP-500模式充满信心 。 最后 ， 将需要时间完善从传统模式到KIP-500模式的升级过程 。
启用KIP-500模式的许多工作将在控制器中进行 。 必须将与ZooKeeper交互的控制器部分与实现更多通用逻辑（例如副本集管理）的部分分开 。
需要定义和实现更多的控制器API ， 以替换当前涉及ZooKeeper的通信机制 。 新AlterIsrAPI 就是一个例子 。 该API允许副本在不使用ZooKeeper的情况下将同步副本集中的更改通知控制器 。
升级版
KIP-500引入了Bridge发行版的概念 ， 该发行版可与KIP-500之前和之后的Kafka版本共存 。 Bridge版本非常重要 ， 因为它们可以实现对ZooKeeper的零停机升级 。 使用旧版Kafka的用户只需升级到网桥版本即可 。 然后 ， 他们可以对缺少ZooKeeper的版本进行第二次升级 。 顾名思义 ， 桥接发行充当了通往新架构的桥梁 。 考虑一个处于部分升级状态的群集 ， 其中桥发行版上包含多个代理 ， 而KIP-500后发行版上包含多个代理 。 控制器将始终是KIP-500之后的Brokers 。 在该群集中 ， Brokers不能依赖直接修改ZooKeeper来宣布他们正在进行的更改（例如配置更改或ACL更改） 。 KIP-500之后的Brokers不会收到此类通知 ， 因为他们没有在ZooKeeper上进行监听 。 通过将其更改镜像到ZooKeeper ， 仅控制器仍在与ZooKeeper交互 。 因此 ， 在Bridge版本中 ， 除控制器外的所有代理都必须将ZooKeeper视为只读 。
用有据可查和受支持的RPC替换临时的ZooKeeper API具有许多与删除客户端ZooKeeper访问相同的好处 。 保持跨版本兼容性将更加容易 。 对于的特殊情况AlterIsrRequest ， 减少普通操作所需的对ZooKeeper的写入次数也将带来好处 。


推荐阅读


上一篇：第五届全球虚拟·现实大会启幕 中国移动咪咕与捷成华视网聚云牵手

下一篇：蓝牙耳机TWS蓝牙耳机什么牌子质量好？音乐耳机品牌排行榜！