Java实现无停机MongoDB schema变更的临时代码处理最佳方案

1. 设计模式选型：策略模式+简单工厂 #

该方案可以将分散在各方法中的重复if判断收拢到统一位置，逻辑解耦清晰，迁移完成后临时代码极易清理，回退成本极低。

实现步骤 #

第一步：抽取公共数据操作策略接口

将原有数据层的所有公共方法抽象为统一接口：

public interface DataLayerStrategy {
    void addElement();
    void deleteElement();
    void updateElement();
    void readElement();
    // 其余原有数据操作方法全量定义
}

第二步：分别实现三种状态对应的策略类

• 旧schema策略类：直接迁移原有旧逻辑即可

public class OldSchemaStrategy implements DataLayerStrategy {
    @Override
    public void addElement() {
        // 原有旧schema插入逻辑
    }
    // 其余方法均按旧schema逻辑实现
}

• 新schema策略类：单独实现新schema的所有操作逻辑

public class NewSchemaStrategy implements DataLayerStrategy {
    @Override
    public void addElement() {
        // 新schema插入逻辑
    }
    // 其余方法均按新schema逻辑实现
}

• 迁移中状态策略类：实现等待重试的统一逻辑

public class MigratingStateStrategy implements DataLayerStrategy {
    @Override
    public void addElement() {
        // 等待迁移完成后重试的逻辑
    }
    // 其余方法复用相同的等待重试逻辑
}

第三步：实现策略工厂类

所有状态判断逻辑收拢到工厂类一处，无需在各业务方法中重复判断：

public class DataLayerStrategyFactory {
    // 策略实例全局复用，无需重复创建
    private static final OldSchemaStrategy OLD_STRATEGY = new OldSchemaStrategy();
    private static final NewSchemaStrategy NEW_STRATEGY = new NewSchemaStrategy();
    private static final MigratingStateStrategy MIGRATING_STRATEGY = new MigratingStateStrategy();

    public static DataLayerStrategy getStrategy(String migrationStatus) {
        return switch (migrationStatus) {
            case "migrated" -> NEW_STRATEGY;
            case "migrating" -> MIGRATING_STRATEGY;
            default -> OLD_STRATEGY;
        };
    }
}

第四步：改造原有数据实现类

原有实现类简化为代理层，所有方法直接调用对应策略即可，无任何冗余判断：

public class MongoDBDataLayerImpl implements <some_class> {
    @Override
    public void addElement(){
        DataLayerStrategyFactory.getStrategy(migrationStatus).addElement();
    }

    @Override
    public void deleteElement(){
        DataLayerStrategyFactory.getStrategy(migrationStatus).deleteElement();
    }

    @Override
    public void updateElement(){
        DataLayerStrategyFactory.getStrategy(migrationStatus).updateElement();
    }

    @Override
    public void readElement(){
        DataLayerStrategyFactory.getStrategy(migrationStatus).readElement();
    }
}

2. 易回退、易清理的优化要点 #

• 所有迁移相关的临时代码（策略类、工厂类）统一添加自定义注解@TemporaryMigration标记，迁移完成后可直接搜索注解批量删除，仅需把原有实现类的方法调用替换为新schema逻辑即可，代码改动量极小。
• 额外增加配置中心全局开关作为兜底，优先级高于数据库迁移状态，出现异常时可一键强制切回旧schema逻辑，无需修改数据库数据，响应速度更快。

3. 不停机schema变更最佳实践 #

• 迁移阶段开启双写逻辑：写入操作同时写入新旧两种schema，读请求优先走旧schema，待全量旧数据迁移完成后再切读请求到新schema，验证无误后再停掉旧schema写入。
• 灰度切流验证：迁移完成后先切10%流量到新schema，观察无异常后逐步提升流量占比到100%，出现问题可随时降流回退。
• 迁移状态变更保证原子性：状态修改操作要加锁避免并发问题，防止出现部分请求走新逻辑、部分走旧逻辑的不一致情况。
• 提前准备回滚预案：预演回滚流程，确保出现问题时可以在1分钟内切回旧schema，无数据丢失风险。

内容的提问来源于stack exchange，提问作者Vajira Prabuddhaka