3. 数据库迁移概述：Schema变更、数据迁移、回滚策略、迁移工具选型
在分布式系统生命周期中，数据库迁移是不可避免的工程活动。它涵盖从Schema结构变更到存量数据迁移，再到失败回滚的全过程。本章将系统梳理数据库迁移的核心概念、常见策略与主流工具选型，为后续章节中异步任务编排与幂等性设计奠定基础。
3.1 数据库迁移的核心维度
数据库迁移通常包含三个相互关联的维度：Schema变更、数据迁移与回滚策略。三者必须协同设计，才能保证迁移过程的正确性与可逆性。
| 维度 | 定义 | 典型场景 | 风险点 |
|---|---|---|---|
| Schema变更 | 修改数据库表结构、索引、约束、存储过程等元数据 | 新增字段、修改列类型、添加唯一索引 | 锁表、兼容性破坏、应用停机 |
| 数据迁移 | 将存量数据从旧结构转换并写入新结构 | 字段拆分、数据清洗、分库分表 | 数据丢失、重复、不一致 |
| 回滚策略 | 迁移失败时恢复到上一个稳定版本的能力 | 版本回退、数据恢复、补偿操作 | 回滚耗时、数据不可逆、依赖链断裂 |
关键原则：任何生产环境的数据库迁移都必须具备可回滚性。没有回滚方案的迁移，本质上是不可控的破坏性操作。
3.2 Schema变更的常见模式
Schema变更并非简单的ALTER TABLE语句。在分布式系统中，变更必须考虑向前兼容与灰度发布。以下是三种经过生产验证的变更模式：
- 新增字段（Add Column）：仅添加允许NULL或具有默认值的列，避免锁表与旧代码报错。
- 重命名/删除字段（Rename/Drop Column）：必须分多步执行：先双写、再迁移、最后清理旧字段。
- 修改约束（Modify Constraint）：优先使用
ALTER TABLE ... VALIDATE CONSTRAINT延迟校验，减少锁持有时间。
最佳实践：使用扩展-迁移-收缩（Expand-Migrate-Contract, EMC）模式。先扩展Schema兼容新旧两版，再逐步迁移数据，最后收缩移除旧结构。该模式天然支持零停机迁移。
3.3 数据迁移策略对比
数据迁移的复杂度取决于数据量、一致性要求与业务容忍的停机时间。下表对比了三种主流策略：
| 策略 | 适用场景 | 停机时间 | 一致性保证 | 实现复杂度 |
|---|---|---|---|---|
| 离线迁移 | 小数据量、允许维护窗口 | 分钟~小时级 | 强一致（单次快照） | 低 |
| 在线双写迁移 | 高可用要求、持续服务 | 零停机 | 最终一致（需校验） | 高 |
| 触发器/CDC迁移 | 大规模数据、增量同步 | 零停机 | 最终一致（依赖日志） | 中 |
注意：在线迁移必须引入幂等写入与数据校验机制。重复执行迁移脚本不应产生重复数据或违反约束，这是后续章节的核心主题。
3.4 回滚策略设计
回滚不是简单的“撤销”，而是需要预先设计逆向迁移脚本。一个完整的回滚策略应包含以下要素：
- 版本化回滚脚本：每个迁移版本都对应一个
rollback.sql，与正向脚本成对出现。 - 数据快照：在迁移前对受影响表创建快照或备份，用于灾难恢复。
- 渐进式回滚：支持按版本逐级回退，而非一次性回滚到初始状态。
- 回滚验证：在预发布环境完整执行回滚流程，验证数据完整性。
-- 正向迁移示例：新增用户状态字段
ALTER TABLE users ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'active';
-- 逆向回滚脚本
ALTER TABLE users DROP COLUMN status;
回滚黄金法则：如果无法写出回滚脚本，就不要执行正向迁移。在分布式系统中，回滚脚本必须经过与正向脚本同等级别的测试与评审。
3.5 迁移工具选型：Flyway vs Liquibase
Flyway与Liquibase是Java生态中最成熟的两款数据库迁移工具。它们都支持版本化管理、自动执行与回滚，但在设计哲学与功能侧重上存在差异。
| 对比维度 | Flyway | Liquibase |
|---|---|---|
| 迁移文件格式 | 纯SQL脚本（.sql） | XML / YAML / JSON / SQL |
| 版本控制方式 | 文件名前缀版本号（如 V1__init.sql） | changelog文件内定义changeSet，支持ID与作者 |
| 回滚支持 | 需手动编写回滚脚本（Undo） | 内置rollback标签，支持自动生成回滚SQL |
| 数据库兼容性 | 支持主流关系型数据库 | 支持更广泛的数据库（含NoSQL部分支持） |
| 学习曲线 | 低（SQL即迁移） | 中（需学习changelog DSL） |
| 分布式场景适配 | 需额外处理锁表与并发 | 支持上下文与预条件，更适合复杂编排 |
选型建议：团队SQL能力强、追求简洁时选Flyway；需要跨数据库、复杂回滚逻辑或非开发人员参与时选Liquibase。在分布式异步迁移场景中，Liquibase的预条件与上下文机制更具优势。
3.6 迁移工具在分布式系统中的架构位置
下图展示了迁移工具在分布式系统部署架构中的典型位置，以及它与应用服务、数据库集群、异步任务编排引擎的关系。
上图展示了迁移工具作为独立组件，位于应用服务与数据库集群之间。它不直接处理业务请求，而是通过异步任务编排引擎触发迁移脚本的执行。这种架构隔离了迁移逻辑与业务逻辑，使得回滚与版本管理更加可控。
3.7 迁移脚本的幂等性设计要点
在分布式异步编排中，迁移脚本可能被重复执行（如网络超时后重试）。因此，迁移脚本必须满足幂等性要求。以下是具体设计要点：
- 使用IF NOT EXISTS / IF EXISTS：在DDL中显式判断对象是否存在。
- 采用MERGE或UPSERT：在DML中避免重复插入导致主键冲突。
- 记录迁移执行状态：在迁移工具内置的
flyway_schema_history或DATABASECHANGELOG表中记录每次执行结果。 - 避免使用自增ID作为业务标识：迁移过程中自增ID可能因重试而跳跃，影响数据一致性。
-- 幂等DDL示例（PostgreSQL）
CREATE TABLE IF NOT EXISTS users (
id BIGSERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
status VARCHAR(20) DEFAULT 'active'
);
-- 幂等DML示例
INSERT INTO users (id, name, status)
VALUES (1, 'Alice', 'active')
ON CONFLICT (id) DO UPDATE
SET name = EXCLUDED.name,
status = EXCLUDED.status;
常见陷阱：不要依赖数据库的唯一约束来保证幂等性。唯一约束只能防止重复，但无法处理部分更新或状态不一致。真正的幂等性需要迁移脚本本身具备可重复执行且结果一致的能力。