融合模式注册表与Spring云模式注册表
我现在一直在查看Spring Cloud模式注册表和汇合模式注册表。我可以看到一些区别，例如Spring Cloud模式注册表将模式保存在普通数据库中，默认情况下保存在h2中，而汇合模式注册表保存在kafka主题中。
spring云模式注册表的这种方法是否会对性能产生任何影响。据我所知，即使数据保留在主题上，以防汇合，查询它时仍然会有延迟。但会有重大影响吗？
我还可以看到，spring云模式注册表提供了对融合模式注册表的支持，这是否意味着融合模式注册表更好？
这些模式注册表的工作有什么根本性的区别吗？
如果融合模式注册表已经可用，那么spring云模式注册表需要什么？
共有1个答案
从Spring云流Kafka的角度来看，建议使用合流模式注册表。将Spring Cloud Stream与融合模式注册表集成起来相当容易。这里有几个样本可以证明这一点。Spring云模式注册表是一个处于维护模式的项目，我们可能不会向其添加任何进一步的功能。如果您使用的是Kafka，那么使用Spring云模式注册表没有多大优势。如果您针对非Kafka中间件系统（如RabbitMQ、AWS-Kinesis等）执行模式演化，Spring云模式注册表可能会很有用。如您所述，默认情况下，它使用H2数据库，您可以为其他数据库配置它。如果您发现Spring Cloud Stream和Confluent Schema Registry之间的集成存在任何问题，请在Kafka Binder GH存储库中提出。
-
我使用来自Confluent的Kafka Connect来使用Kafka流并以拼花格式写入HDFS。我正在1个节点中使用架构注册表服务，它运行良好。现在我想将模式注册表分发到集群模式以处理故障转移。关于如何实现这一点的任何链接或片段都将非常有用。
-
我们正在开发并尝试删除主题的模式，因为更改与旧模式不兼容。 我们删除了模式/主题，并尝试使用相同的主题名称创建新模式，成功创建了模式。 然而，当我们运行应用程序时，它仍然指向相同的模式ID。 旧模式ID（主题“topic1”）：51 新架构ID（主题“topic1”）：52 应用程序在反序列化消息时出错 <代码>root@bas：/#curl-khttps://schemaregistry:443
-
我正在尝试使用Confluent schema registry，下面是我在Github中找到的一些示例(https://github.com/gAmUssA/springboot-kafka-avro). 当消费者和生产者与模型共享相同的命名空间而不是其工作时。 当使用者位于具有不同名称空间但具有相同类（名称和属性方面）的不同项目中时，它不工作。 合流Avro反序列化程序可以使用正确的值反序列化
-
我正在了解Confluent的模式注册表，以满足所有模式管理需求。 我不太理解他们的版本控制方法...有一个的概念，我将其视为一个名称空间。据我所知，subject在模式注册表中必须是唯一。 然后是模式id，或者只是，它也是唯一的。 最后，还有一个。 以下是文档中的片段： :此主题的架构版本，每个主题从1开始 :全局唯一的架构版本id，在所有主题中的所有架构中都是唯一的 因此，一旦我想修改特定主题
-
有可能将融合模式注册与AWS MSK集成吗？如果你以前这样做过，你能提供一些你实现它的方法/博客吗？
-
我正在与Avro/Kafka和Confluent的Avro模式注册中心合作。 我使用avsc文件和avdl制作了一些基本模式和具有基本类型的主题。 我正在查看Confluent制作的API文档，以尝试将模式发展到版本2。特别是本部分： https://docs.confluent.io/current/schema-registry/using.html#register-a-new-versio