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

2
技术选型：为什么是 MySQL ，又不仅是 MySQL
决定去 Oracle 之后，选择什么数据库或存储引擎来承载 Oracle 的流量？我们从功能、资源、案例和压测四个方面来进行选型和评估。

本文插图
首先，选择的数据库要从功能和性能上能够承接 Oracle 在各种场景下计算和 IO 能力。其次，它还要具备最广泛的社区资源、技术资料和问题处理案例，通俗的说就是大量坑被踩过，以及最广泛的用户基础，外面招开发和运维工程师都比较好招。然后，还要在业界有可参考的金融场景案例。这一点相信大家都很熟悉，阿里和腾讯在金融场景上已经有不少成功的案例。
最后，同时也是最重要的一个评估标准就是陆金所自身上线前严格的压测环节。陆金所在切换任何一张表流量的时候，都会使用生产环境完全真实的数据搭建 O 和 M 并行压测环境，来获取访问这张表的所有读写接口的在 Oracle11.2 和 MySQL5.7 下的性能比对报告。经过每一轮非常严格的压测后，发现 MySQL5.7 的性能比我们预估中的更好。通过从边缘系统往核心系统的逐步去 O 演进中， MySQL5.7 就成为陆金所去 O 最主要的替代存储引擎。
我们都知道 Oracle 是个非常优秀、且覆盖场景非常全面，无论是 OLTP 还是 OLAP 场景表现都很优秀，所以这种功能承接应该远远不止一种数据库或存储引擎，涉及到多种存储引擎发挥他们的优势在各种特定场景下来替换 Oracle 。
所以最终的结论是综合选型下来确定使用 MySQL 为主， TiDB、Redis、ES、HBase 等多种存储引擎为辅的方式， 100% 全部替换掉 Oracle 。
3
陆金所去 Oracle 方案
接下来，我们就详细介绍陆金所的去 Oracle 方案。
去 O 双写和切换方案

本文插图
陆金所去 Oracle 改造主要是分为应用和数据库两个部分来落地的。
首先介绍一下应用层部分的落地。应用层在去 O 的时候会做一个整体规划，把一个大的系统或库拆分成多个可独立落地的批次，然后会把应用的业务逻辑层从数据库的访问接口尽可能剥离出来，让 DAL 层专注只做好数据库交互的操作。同时，在 Oracle DAL 层的基础上，对 MySQL DAL 层的进行重构，并且配置流量开关让上层的业务逻辑层可以自由选择和数据库的交互是走 Oracle DAL 层还是 MySQL DAL 层。每个批次都会有自己单独的流量开关进行控制。批次拆分的时候遵循一个原则就是把具备业务相关性和事务相关性的表放在一个批次里。
再说数据库层的落地，在 Oracle 还在不断对外提供服务的时候，我们会在后台建立起一个和 Oracle 保持实时数据同步的 MySQL 数据库，即当 Oracle 的事务提交后，秒级同步到后端的 MySQL 里面。同时这个同步是双向的，当未来流量切换到 MySQL 后，也会在 MySQL 事务提交完成后，把数据秒级同步回 Oracle ，这就类似 MySQL 的双 master 架构，只不过数据是在 Oracle 和 MySQL 这个异构数据库之间建立双 master 架构。
在这个架构中为了确保数据库的一致性和完整性，一定是严格要求某个批次的写流量只能在某个时间点只能在 O 和 M 一个地方写入。陆金所研发了一整套自动化构建数据库双写的工具平台，只要在平台上选择需要建立批次的 Oracle 表，就能在后台全自动完成 Oracle to MySQL 从表结构转化、数据全量同步、数据增量同步、数据实时同步、数据校验和数据双向同步建立整个全流程繁琐。依据这套自动化平台，陆金所只投入 2 个 DBA 就完成了全站上万张表的去 O 数据库迁移和运维层的全部准备工作。