合流模式注册表
我正在了解Confluent的模式注册表，以满足所有模式管理需求。
我不太理解他们的版本控制方法...有一个subject的概念，我将其视为一个名称空间。据我所知，subject在模式注册表中必须是唯一。
然后是模式id，或者只是id，它也是唯一的。
最后，还有一个版本。
以下是文档中的片段：
版本:此主题的架构版本，每个主题从1开始
id:全局唯一的架构版本id，在所有主题中的所有架构中都是唯一的
因此，一旦我想修改特定主题下的模式，id和version字段会发生什么？id是否更改？版本是否增加？
另一句引语：
当模式演变时，它们仍然与相同的主题相关联，但获得新的模式ID和版本
是否每个更改都需要新的ID和新的版本？
共有1个答案
每个主题都有一个版本列表。如果您愿意，您可以在源代码中验证这一点。
如果两个主题共享相同的模式，则模式ID是相同的，尽管两个不同主题中的版本可能不同。参见下面的示例。
每个唯一的模式（由其文本表示定义）都有一个唯一的（可能是增量的）ID。它们是MD5散列的，或“指纹”的唯一性，然后在模式注册中心集群之间进行全局比较。这是使用concurrenthashmap
的等价物完成的，其中键是valueschema对象的哈希值
示例：对主题、版本和架构使用sub、v和s
- 创建sub1，使v1:s1
- 更新它以创建v2:s2
- 采用相同架构并使用它创建sub2
sub1:[V1:S1,V2:S2]
sub2:[V1:S2]
-
我希望即使服务器重新启动，也能保持一个具有固定id的模式。 是否可以在模式注册表中保存模式，以便在服务器崩溃后使用相同的id？ 否则，是否有可能在模式注册表服务器启动时用固定的id硬编码一个模式？
-
我现在一直在查看Spring Cloud模式注册表和汇合模式注册表。我可以看到一些区别，例如Spring Cloud模式注册表将模式保存在普通数据库中，默认情况下保存在h2中，而汇合模式注册表保存在kafka主题中。 spring云模式注册表的这种方法是否会对性能产生任何影响。据我所知，即使数据保留在主题上，以防汇合，查询它时仍然会有延迟。但会有重大影响吗？ 我还可以看到，spring云模式注册表
-
我试图使用Confluent_Kafka的AvroProducer类生成Avro格式的消息。Kafka和Schema-Registry在同一个网络中作为3个节点的集群运行。 我得到的是 我没有使用Docker容器。集群由3个独立的VM组成，其中安装和运行Kafka和Registry Schema，所以它也不是独立的。Python代码从具有网络访问和防火墙异常的第四个VM执行。事实上，我可以在没有a
-
我使用来自Confluent的Kafka Connect来使用Kafka流并以拼花格式写入HDFS。我正在1个节点中使用架构注册表服务，它运行良好。现在我想将模式注册表分发到集群模式以处理故障转移。关于如何实现这一点的任何链接或片段都将非常有用。
-
我试图用函数编程（和spring cloud stream）转换来自输入主题的输入AVRO消息，并在输出主题上发布新消息。下面是我的转换函数： 我的spring boot应用程序是以这种方式声明的，并激活了模式注册表客户机： 谢谢你能给我带来的任何帮助。 视CG
-
我正在尝试设置一个Beam管道，以便使用python API读取Kafka的内容。我能够设置消费者配置和主题。如何更新管道以使用合流模式注册表并定义Avro消息值反序列化器？