场景特点
银行核心交易系统的数据库替换，通常被视作难度最高的一类迁移。原因不在于数据量，而在于对正确性的零容忍：账务数据一旦出现不一致，影响的是真实的资金，任何「最终会一致」的说法都不被接受。
这个场景的典型约束包括：
- 强一致事务：跨账户转账必须原子生效，不能存在中间态；
- 高可用要求：系统停机窗口极短，且需具备机房级容灾能力；
- 性能不可退化：交易响应时间有明确上限，替换后不得明显变慢；
- 可审计：每一次数据变更都需要可追溯，满足监管要求。
架构对应的能力
分布式数据库之所以能进入这个场景，靠的是几项可以逐条验证的能力：
- 分布式事务与全局时间戳：通过两阶段提交保证跨节点写入的原子性，配合全局授时建立事务全序，确保不会读到中间态；
- 多副本强一致复制：写入需多数派确认才提交，单副本故障不丢数据；
- 可配置的副本拓扑：通过副本放置策略实现同城多机房甚至两地多中心部署；
- 自动故障转移：副本故障时自动选出新主，无需人工介入，缩短恢复时间。
容灾拓扑的取舍
容灾级别与写入延迟之间存在直接冲突，这是本场景最需要权衡的地方：
- 同城多机房：可容忍机房级故障，同城网络延迟低，对交易响应时间影响可控，通常是核心交易的首选；
- 两地多中心：可容忍城市级故障，但跨城复制会显著抬高写入延迟，需要评估是否所有交易都需要跨城强同步；
- 混合策略：核心账务采用同城强同步保障一致性，异地部署异步副本用于灾难恢复，用可接受的恢复点目标换取性能。
关键结论：容灾方案应当由业务的「可容忍停机时长」与「可容忍数据丢失量」倒推，而不是一味追求最高级别。
迁移节奏
核心系统不会一次性整体切换，常见的推进方式是分层分步：
- 外围系统先行：从查询类、报表类、渠道类系统开始替换，积累运维经验；
- 次核心业务跟进：涉及资金但可容忍短暂异常的模块；
- 核心账务最后迁移：在前面积累的经验与工具链基础上推进，并保留完整回滚路径；
- 双跑验证：关键业务在切换前后并行比对结果，确认一致性后再停用旧系统。
必须做的验证
- 事务一致性验证：构造并发转账、跨账户操作等场景，确认无中间态、无重复扣款；
- 性能回归：用真实交易流水回放压测，关注延迟分位而非仅看平均值；
- 故障演练：主动下线副本、模拟机房网络中断，验证自动故障转移的实际耗时；
- 长事务排查：核心系统中最易被忽略的风险，需要建立监控与告警；
- 数据校验：迁移后做全量校验和比对，行数一致不代表内容一致。
经验小结
金融核心场景的迁移，技术方案只是其中一半，另一半是流程与验证体系。把每一步都做成可验证、可回滚的动作，把性能与一致性指标量化成验收标准，替换才具备可控性。相比之下，「选一个更强的数据库」反而是最简单的一步。
| 行业场景 | 银行核心账务与交易系统，对正确性与容灾要求最高 |
|---|---|
| 核心诉求 | 强一致事务、机房级容灾、性能不退化、变更可审计 |
| 关键能力 | 两阶段提交与全局时间戳、多副本多数派提交、自动故障转移 |
| 拓扑取舍 | 同城多机房优先保障延迟，异地异步副本用于灾难恢复 |
| 推进方式 | 外围先行、次核心跟进、核心最后迁移，保留双跑验证与回滚路径 |
