Java 使用特定Id将架构添加到架构注册表

我们已经在KafkaStreams中使用Confluent Schema Registry一年多了，一切都很好；直到昨天

在UAT环境中，我们似乎删除了一个模式主题，并且我们的一个应用程序开始使用消息进行故障转移

[错误]LogAndFailExceptionHandler-在执行过程中捕获异常 反序列化，任务ID:0\u 13，主题：主题名称，分区：13， 偏移量：0 org.apache.kafka.common.errors.SerializationException:错误 正在检索id为1531的Avro架构

我检查了模式注册表，发现主题丢失，并使用curl查询错误中列出的id 1531，例如：

curl -X GET http://SchemaRegistryHost:8081/schemas/ids/1531

然后回来了：

{"error_code":40403,"message":"Schema not found"}

我天真地尝试重新注册模式，但没有考虑它，它工作了，但模式注册的id与之前的1531 id不一样

我需要将模式注册到ID1531，因为主题中的现有消息已经在魔法字节中包含ID1531

我在上查看了API文档，但没有看到任何关于为模式设置给定Id的内容

是否仍然需要使用schema registry将架构强制为特定Id

我知道有一些备份解决方案，但我现在正在寻找一种修复方法，希望能够防止数据丢失，或者采取非常措施来修复主题数据

是否仍然需要使用schema registry将架构强制为特定Id

没有

---

1531的ID实际上并没有“消失”，顺便说一下，它只是在注册表中被标记为已删除（使用

\u schemas

主题查看它）

---

我知道，当你使用卡夫卡夫罗德列化器时，这个错误是无法避免的。您必须使用ByteArraydSerializer，然后使用Schema注册表客户端“修复”或“查找”正确的ID，然后反序列化消息的其余部分

---

另一个选项是重置消费者组，以便完全跳过这些消息，或者设置异常处理

好消息是，这只是一个UAT环境，因此，如果我们“跳过”数据，这并不是世界末日，但这似乎是在生产环境中发生的，因为跳过消息会产生实际的财务成本，这将不是一个可接受的解决方案。另外，备份生产模式注册表并对删除模式主题进行更好的控制似乎也非常关键。。。虽然看起来像汇合应该考虑扩展API允许在这些类型的恢复情况下使用这样的用例。没有办法“取消它被删除”这似乎是一个相当严重的事件，如果没有办法恢复这一点。我读得越多，就越不愿意使用confluent@MiguelCosta模式数据存储在Kafka中，这意味着它是仅附加的，不存在“回滚”。因此，删除是永久的。