问题背景
在2024年3月7日，系统消费 RocketMQ 消息时出现了序列化报错，错误信息显示为：
java.io.InvalidClassException: com.xxx.xxx.bean.mg.GoodsChangeLogMessage; local class incompatible: stream classdesc serialVersionUID...
这是典型的序列化问题，导致消息无法被正确消费。
问题描述
在 RocketMQ 消息消费过程中，出现了 serialVersionUID 不一致的错误。这是由于 GoodsChangeLogMessage 类的属性发生了修改，导致序列化版本 ID 发生了变化，从而无法反序列化以前发出的消息，报错内容涉及 InvalidClassException，这是 Java 反序列化时的常见异常，表示当前类的序列化版本与序列化流中的版本不匹配。
问题原因
属性变更：
GoodsChangeLogMessage类的属性有过修改，导致serialVersionUID发生了变化，而在 Java 序列化中，serialVersionUID是用于标识类的版本的，如果这个 ID 发生变化，则无法反序列化之前保存的对象。未指定
serialVersionUID：当类实现了Serializable接口但没有指定serialVersionUID时，JVM 会根据类的结构自动生成一个序列化版本 ID，这意味着每次修改类结构都会生成一个新的serialVersionUID，从而导致之前的序列化对象与新类不兼容。消息格式未处理：消息发送时直接发送了实体对象，而不是将对象转换为 JSON 字符串，这导致使用 Java 的默认序列化方式，在涉及到不同版本的实体类时，容易产生序列化问题。
解决方案
1. 指定 serialVersionUID
为了避免 serialVersionUID 随类修改而变化，所有实现了 Serializable 接口的类必须显式地指定 serialVersionUID，以确保类修改后仍然可以兼容之前的序列化对象。
例如：
private static final long serialVersionUID = 1L;
这样，即使类属性发生变化，序列化版本 ID 也不会改变，仍然可以正确反序列化老的对象。
2. 使用 JSON 格式传输消息
RocketMQ 默认使用 Java 的序列化机制，但这并不是跨平台的最佳实践。为了解决异构系统和版本兼容性问题，建议将实体对象转换为 JSON 字符串进行传输。JSON 格式不仅可以减少序列化版本不一致的问题，还可以支持更多的语言处理。
发送消息时，可以通过以下方式将实体对象转换为 JSON：
String messageContent = JSON.toJSONString(goodsChangeLogMessage);
然后发送这个字符串，而不是发送原始的实体对象。
3. 引入版本控制策略
在系统的迭代过程中，可能无法完全避免类的修改。因此，对于重要的消息对象，可以考虑引入版本控制机制。在对象中包含一个 version 字段，用来标识当前对象的版本。在消费端可以根据版本进行相应的兼容处理。
预防措施
始终指定
serialVersionUID：确保所有需要序列化的类都明确声明serialVersionUID，即使类结构发生变化，也可以避免反序列化失败。使用 JSON 或其他通用格式传输数据：JSON 格式具有广泛的兼容性，特别是对于需要支持不同语言的场景，避免了 Java 的序列化机制带来的问题。
消息协议规范化：定义好跨版本和跨平台的消息协议，确保系统在更新时能更好地兼容旧数据，避免序列化问题。
关注类的修改：在类发生修改时，确保对其影响范围有清晰的认识，特别是对于可能已经持久化或缓存的序列化对象，需小心处理版本兼容性问题。
总结
这次 RocketMQ 序列化报错的根本原因是由于未指定 serialVersionUID，导致类的属性修改后无法反序列化旧的消息。通过显式指定 serialVersionUID 和使用 JSON 格式传输消息，可以有效避免类似问题的发生。