4、状态复用设计原则：状态与业务解耦、状态Schema版本管理、状态序列化与反序列化

状态复用这件事，说起来简单，做起来全是坑。我见过太多团队，一开始图省事，把业务逻辑直接揉进状态里，结果半年后想复用状态，发现根本拆不开。说白了，状态复用不是技术问题，是设计问题。

这一章，我把自己踩过的坑、总结出来的原则，掰开了讲给你听。核心就三条：状态与业务解耦、状态Schema版本管理、状态序列化与反序列化。这三条做好了，状态复用就是水到渠成的事。

4.1 状态与业务解耦：别让状态变成“业务大杂烩”

先问一个问题：你的状态里，到底该存什么？

很多人会把业务字段直接塞进状态。比如一个订单统计任务，状态里存了orderId、userId、amount、status，甚至还有userName。嗯，当时写起来确实爽，但后来要复用这个状态给另一个流任务，发现userName根本用不上，还得做数据清洗。

我个人习惯，把状态分成三层：

层级	内容	举例
业务无关层	计算所需的中间结果、聚合值	计数、求和、最大值、最小值
业务弱相关层	业务标识、时间戳、分区键	orderId、eventTime、partitionKey
业务强相关层	业务逻辑推导出的衍生字段	用户等级、订单类型、风险标签

状态复用，重点复用的是业务无关层和业务弱相关层。业务强相关层，说白了，换个业务场景就得重算。

我在项目中遇到过这样一个案例：一个实时UV统计任务，状态里存了userId、deviceId、ip、userAgent。后来要复用这个状态做跨天去重，发现userAgent根本没用，还占内存。重构后，状态只保留userId和eventDate，内存直接降了40%。

4.2 状态Schema版本管理：给状态加个“身份证”

状态不是写死就不动了。业务迭代、字段变更、类型调整，都是家常便饭。没有版本管理，状态升级就是一场灾难。

我建议，每个状态都带一个schemaVersion字段。就像给状态加了个“身份证”，一眼就能看出它是哪个版本的。

// 状态Schema示例
public class OrderAggState {
    private int schemaVersion = 1;  // 版本号，必须第一个字段
    private long orderCount;
    private double totalAmount;
    private long lastUpdateTime;
    
    // 版本2新增字段
    private double maxAmount;  // schemaVersion=2时才有值
}

版本管理的核心逻辑，我总结成三步：

1. 写入时标记版本：每次状态更新，都带上当前schemaVersion。
2. 读取时校验版本：反序列化时，先读版本号，再决定怎么解析。
3. 升级时兼容处理：旧版本状态，通过升级函数转成新版本。

我曾经遇到过一个线上事故：状态Schema从v1升到v2，新增了一个discountRate字段。结果升级脚本没写兼容逻辑，旧状态反序列化直接抛异常，整个任务重启了三次才修好。嗯，从那以后，我强制要求每个状态变更都必须写向前兼容的升级函数。

4.3 状态序列化与反序列化：选对工具，事半功倍

序列化这事，看似简单，其实门道很多。选错了，性能差十倍；用对了，状态复用就像喝水一样自然。

我常用的序列化方案对比：

方案	优点	缺点	适用场景
Java原生序列化	开箱即用，无需额外依赖	性能差，体积大，有安全风险	不推荐，除非是玩具项目
Avro	Schema演进友好，压缩率高	需要定义Schema文件，学习成本	长期维护、频繁升级的状态
Protobuf	性能极佳，跨语言支持好	需要编译生成代码，调试不便	高性能、跨语言的状态复用
Kryo	速度快，体积小，使用简单	Schema演进支持弱	短期任务、内部使用的状态
JSON	可读性强，调试方便	体积大，解析慢	小状态、调试阶段

我个人习惯，生产环境首选Avro。为什么？因为Avro的Schema演进机制最成熟。你想想看，状态复用最大的痛点就是版本不一致，Avro的readerSchema和writerSchema分离机制，天然支持向前兼容和向后兼容。

4.4 状态复用设计全景图

说了这么多，我把这三条原则的关系画成一张图，方便你理解：

4.5 实战：状态复用代码模板

光说不练假把式。我给你一个我项目里实际用过的状态复用模板，结合了Avro序列化和版本管理。

// 状态定义（Avro Schema自动生成）
public class ReusableState {
    private int schemaVersion;
    private long count;
    private double sum;
    private Map<String, Double> dimensionMap;
    
    // 升级函数：v1 -> v2
    public static ReusableState upgradeFromV1(StateV1 oldState) {
        ReusableState newState = new ReusableState();
        newState.schemaVersion = 2;
        newState.count = oldState.getCount();
        newState.sum = oldState.getSum();
        newState.dimensionMap = new HashMap<>();
        // v1没有dimensionMap，初始化为空
        return newState;
    }
}

// 状态序列化器
public class ReusableStateSerializer {
    private static final int CURRENT_VERSION = 2;
    
    public byte[] serialize(ReusableState state) {
        // 使用Avro序列化，自动写入schemaVersion
        return avroSerializer.serialize(state);
    }
    
    public ReusableState deserialize(byte[] data) {
        // 先读版本号
        int version = readVersion(data);
        if (version == CURRENT_VERSION) {
            return avroDeserializer.deserialize(data);
        }
        // 旧版本，先反序列化再升级
        StateV1 oldState = v1Deserializer.deserialize(data);
        return ReusableState.upgradeFromV1(oldState);
    }
}

好了，状态复用的三条设计原则，就讲到这里。记住：解耦是前提，版本是保障，序列化是工具。这三条做好了，状态复用就是顺理成章的事。