时间戳

首页 > 解决方案 > Confluent 的架构注册表如何分配架构 ID？

apache-kafka - Confluent 的架构注册表如何分配架构 ID？

问题描述

我正在使用CachedSchemaRegistryClientandregister方法，它采用主题和Avro模式。我正在针对5.2.1融合的 docker 图像运行这些，当我注册模式时，我得到了我觉得奇怪的行为。

我注册的第一个架构返回一个idof 81（通过使用架构注册表 REST api 备份以检查此架构是否与 this 绑定id），然后第二个架构返回 121 的 id。

由于这种行为是出乎意料的，而且我无法通过谷歌找到答案，我很好奇是否有散列策略或类似的东西来分配模式 id，我希望它从 1 开始并递增。

标签： apache-kafkaconfluent-platformconfluent-schema-registry

解决方案

Confluent 文档解释了如何将唯一 ID 分配给模式：

Schema Registry 是 Avro Schemas 的分布式存储层，它使用 Kafka 作为其底层存储机制。一些关键的设计决策：

  • 为每个注册的模式分配全局唯一 ID。分配的 ID 保证是单调递增的，但不一定是连续的。
  • Kafka 提供持久的后端，并用作 Schema Registry 状态及其包含的模式的预写变更日志。
  • Schema Registry 设计为分布式，单主架构，ZooKeeper/Kafka 协调主选举（基于配置）。

还，

架构 ID 分配

Schema ID 分配总是发生在主节点中，并且 Schema ID 总是单调递增的。

如果您使用 Kafka 主选举，则 Schema ID 始终基于写入 Kafka 存储的最后一个 ID。在主节点重新选举期间，只有在新主节点赶上存储中的所有记录后才会进行批量分配<kafkastore.topic>。

如果使用 ZooKeeper 主选举， /<schema.registry.zk.namespace>/schema_id_counterpath 存储当前 ID 批次的上限，新批次分配由主选举和当前批次耗尽触发。这种批量分配有助于防止潜在的僵尸主场景（例如，如果前一个主节点的 GC 暂停持续时间超过 ZooKeeper 超时，则会触发主节点重新选举）。

推荐阅读