InfoQ去Oracle实录：如何在线更换金融核心场景中的数据库？( 三 )

最后是流量切换，我们设计并研发了一套总控开关机制来协调从应用、到数据库、到传输、最后到流向的全盘流量切换。实现当流量在 O 时，实时同步到 M 。当流量在 M 时，实时同步到 O 。保证切换一瞬间，最后一笔事务在源库提交成功，在目标库传输成功，并完成最后一笔事务的数据在源库和目标库的数据校验后，同一个批次下所有表的写流量在同一个时间点同时完成切换。
应用流量在 O 和 M 之间快速切换

本文插图
虽然去 O 流量切换会在 10 秒内瞬间完成，但整个过程按照细粒度划分会有十多个步骤。为了方便介绍，我们把这十几个步骤精简成了三个状态。
首先是初始状态，这个状态下生产的只读流量可以在 Oracle 或 MySQL ，写流量可以在 Oracle ，由 Oracle 对外提供服务。这个状态状态可以理解为 Oracle 为主库， MySQL 为 Oracle 的异构实时备库。
其次是中间状态，这个状态下 Oracle 和 MySQL 会进入一个非常短暂的写保护静止状态。在完成最后一笔 Oracle 事务提供成功，并同步至 MySQL ，且完成最后一笔数据一致性校验后，会把应用开关的流量切换到 MySQL ，这个时候这个批次的写流量在某个时间点全部一致性都切换到 MySQL 。
一旦在 MySQL 里写流量进来，就进入了第三个状态即完成状态，一旦写流量的事务在 MySQL 中提交成功，双向实时同步链路会把 MySQL 的数据秒级同步回 Oracle ，这个时候可以理解为 MySQL 是主库， Oracle 是 MySQL 的实时备库。
需要注意的是，这个架构下需要解决大量的细节问题，比如避免同一笔记录双向循环写的问题。
陆金所实现的这个双写框架流量切换速度极快，在数秒内就能实现有状态的写流量从 O 到 M 的快速切换，整个过程在低峰期落地对业务影响非常小，甚至是不感知。如果在去 O 之前在 Oracle 内部已经完成了对用户的水平拆分，以批次和用户双重细粒度进行去 O 流量切换，那么整个更换数据库过程几乎是无感的。
在流量从 O 切换到 M 后，以陆金所落地的经验来看，大概有一定概率（比如程序的 bug）需要回切到回 Oracle 。这套切换框架可以确保在几秒内流量快速回到 Oracle ，且在 MySQL 写入的少量数据也会同步会 Oracle ，且在保证 Oracle 和 MySQL 两边的数据严格一致性和完整性的过程中，进行流量的快速前滚和回滚。
适用于金融核心系统的稳妥去 O 推进方案

本文插图
了解了去 O 流量切换的架构和方案，接下来我们介绍如何在一个关联系统庞大、业务逻辑复杂、改造风险极高的金融核心系统里落地整个去 O 方案。
首先我们会以表为粒度来把一个复杂、庞大的金融核心系统和数据库拆分成多个批次，拆分的原则上面也提到了一点，即把有业务相关性和事务相关性的表放在同一个批次里，在确保这个基本原则的情况下，把单个大库尽可能的拆分成多个批次，确保每个批次里的表尽可能的少。
为什么要基于这个原则来落地实施呢，因为批次是去 O 变更的单位， O 和 M 之间的流量切换开关是控制到批次的。把批次拆分的足够细，最终目标是为了实现“改造难度可控、上线进度可控、切换风险可控”的 3 原则。
首先对于金融核心系统中一个复杂的模块来说，去 O 改造的周期会横跨半年甚至一年以上，在这个过程中，金融核心系统在 7*24 小时不间断对外提供服务，应用层的代码和功能每个月甚至是每周也处在高速迭代中，不断的新功能被加入到系统并被发布到生产。
而在这个过程中，要落地去 O 这类庞大的架构改造，必须框定一个可快速迭代和实施的改造范围，批次就是一个合理设定的单次去 O 改造和变更的范围。批次拆分的粒度细，可以确保在单个批次的去 O 改造工作量可控、改造难度也可控。