如果字段顺序更改，Avro 架构不兼容

设想 - 客户端使用 Avro Reflect Datum Writer 序列化 POJO 并将 GenericRecord 写入文件。 通过反射获得的模式是这样的（注意顺序A、B、D、C）-

{
"namespace": "storage.management.example.schema",

"type": "record",
"doc": "Example schema for testing",
"name": "Event",
"fields": [
     ....
     ....
    { "name": "A", "type":  "string"  },
    { "name": "B", "type":  "string"  },
    { "name": "D", "type": "string" },
    { "name": "C", "type":  "string"  },
     ....
     ....
]
} 

代理读取文件并使用默认模式（注意顺序 - A、B、C、D）来反序列化记录的子集（保证客户端拥有这些字段）

{
"namespace": "storage.management.example.schema",
"type": "record",
"doc": "Example schema for testing",
"name": "Event",
"fields": [
    { "name": "A", "type":  "string"  },
    { "name": "B", "type":  "string"  },
    { "name": "C", "type": "string" },
    { "name": "D", "type":  "string"  }
]
}

问题 ： 使用上述子集模式的反序列化会导致以下异常 -

Caused by: java.io.IOException: Invalid int encoding
at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:145)
at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259)
at org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201)
at org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:430)
at org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:422)
at org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:180)
at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:152)
at org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:240)
at org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:230)

但是，如果子集模式还按 A、B、D、C 的顺序指定字段，则反序列化会成功。（与客户端模式相同）

这种行为是预期的吗？我认为 Avro 仅依赖于字段名称来构建记录，而不依赖于排序。

有什么解决办法吗？不同的客户端可能有不同的顺序，我无法强制排序，因为模式是通过反射生成的。

这不一定是预期的行为。您可能会犯与我开始使用 Avro 时所犯的错误相同的错误。

Avro 能够拥有不同版本的模式（例如，用一个模式写入但读入另一个模式），但很容易错过的一件事（至少我自己）是您必须拥有尝试读取消息时写入消息的确切架构。

您阅读的有关 Avro 的文档和信息（至少在表面上）并没有非常清楚地说明这一点。通常他们关注它的“向后兼容”。公平地说，从某种意义上来说是这样，但通常当人们看到这个短语时，他们会认为它的含义有点不同。通常我们认为这意味着您可以使用新模式处理旧消息，而不是使用新模式处理旧消息和旧消息的架构。

作为示例，请参阅此伪代码

Schema myUnsortedSchema has C B A order
Schema myAlphabeticalSchema has A B C order

Writer writer uses myUnsortedSchema
Reader badReader uses myAlphabeticalSchema only

writer writes message
badReader reads message

错误！不确定错误消息到底会说什么，但问题是badReader不仅尝试阅读myAlphabeticalSchema还可以阅读该消息，就好像它是由myAlphabeticalSchema。解决方案是有一种方法可以为其提供两种模式，一种是写入消息的模式，另一种是要读取的模式（具体方式取决于语言）。

Reader goodReader reads messages written with myUnsortedSchema into myAlphabeticalSchema

goodReader reads message

没有错误！这是正确的用法。

如果您使用类似的方法goodReader那么这种行为是意外的，但是如果您使用类似的方法badReader那么该行为是预期的。

某些服务（例如架构注册表）可以通过将一些元数据附加到消息字节的前面来确定哪个架构写入了消息（当然，并在读取之前将其剥离）来帮助解决此问题。这超出了问题的范围，但可以帮助解决这样的问题。