关于数据库:陆金所金融核心场景数据库的去-O-之路

5次阅读

共计 3277 个字符，预计需要花费 9 分钟才能阅读完成。

作者介绍: 万霁春，陆金所数据架构 DBA 团队经理。

金融行业该如何在线替换金融外围场景数据库？在 TUG 陆金所企业行流动中，来自陆金所的数据架构 DBA 团队经理万霁春老师分享了陆金所的去 O 之路，以下内容整顿自当天流动分享实录。

陆金所全站去 O 我的项目从 2018 年中开始，整个我的项目迁徙过程中没有做任何的服务降级，在不影响线上业务的状况下，把全站 100% 的数据库从 Oracle 无缝迁徙到开源和国产数据库上，其中包含：MySQL、TiDB 及其他开源数据库。

整个迁徙过程零故障、零危险，对用户来说齐全没有感知。陆金所去 O 数据库笼罩基金、网贷、信托、资管等全金融场景，同时也包含金融零碎最外围的账务、资金、领取、交易和资产零碎，目前都曾经运行在国产开源数据库下面。

在金融外围零碎继续对外提供服务的状况下，实现更换全套数据库是极具挑战性的架构革新工作。

去 O 我的项目咱们把它称之为 CTO 我的项目，这个我的项目听下来是由纯运维或 DBA 团队来主导施行的我的项目，但实际上替换一个异构数据库在实质上是齐全不同的，它波及到业务零碎、利用零碎里所有的 SQL 代码，换一个数据库就要依据新的数据库语法进行逻辑重构，所以这个我的项目的停顿中岂但有 DBA，有利用开发，还有整个架构团队。引入一个新的数据库系统会波及到架构标准、开发标准、中间件引入等问题，须要架构团队进行反对，一些 SQL 语句跟原来的应用办法齐全不一样，其下层的业务逻辑须要进行批改，包含测试、开发、产品经理、业务方，在某些状况下也须要染指。

在这样一个多团队参加的我的项目中，去 O 过程须要有严格的规范，并且要有严格的流程去监控这些规定是否无效落实到每一行代码的革新和变更上，否则任何一个环节呈现失误都可能导致数据迁徙过程中不统一，或者业务逻辑在迁徙过程中发生变化。

金融零碎去 O 分为以下四个步骤：

第一，应用层的服务化革新；
第二，从 Oracle 数据库到开源数据库的数据字典的转换，包含数据的迁徙，以及迁徙后云端和指标端数据一致性的校验；
第三，从 Oracle 到开源数据库的 SQL 代码语法适配革新和存储过程革新；
第四，怎么在不停机的状况下把原来在 Oracle 下面的读写流量以十分快、十分稳当的形式切换到新的数据库下面，并且在切换之后，呈现问题能够随时回滚。

其中提到的第一点就是服务化革新。在传统的架构上 Oracle 数据库会用得特地大、特地重，数据量动辄十几个 T、几十个 T，这些数据可能囊括陆金所所有业务线数据，因而一个数据库会被下层几十个、上百个利用同时连贯、拜访，进行读写操作。

在这种架构中，去 O 工作很难无效推动，因为如果要迁徙一张表，可能下层有很多关联的利用要同时进行革新，利用间的相互依赖、互相耦合会制约我的项目的停顿。所以咱们第一步是把这些数据库对象的下层利用进行服务化，规定某一个库，某一个 Schema 的某些表只能由某一个特定利用来拜访，这样其余要拜访这些数据的关联利用就调用他的属主利用进行数据的读写操作的拜访。这样的话，咱们在去 O 的革新过程中只有对这一个属主利用进行革新，其余相关联调动利用就不须要关怀底层用的是什么数据库。

服务化革新之后，咱们为了去 O 我的项目的疾速迭代，能够在多个拆分后的业务域的属主利用上面进行去 O 革新，因为互相的耦合性曾经解开了，所以整个代码革新能够并行开始。

基于这套方法论，咱们总结出一套流水线式的开源数据库的革新计划。

第一，高效数据库异构迁徙，能够一键全自动化地把原来 Oracle 上的数据库表对象间接做完数据字典的转换，把数据迁徙到新的数据库下面；
第二，为了便于利用代码的 SQL 革新而做了一个 SQL 智能转换的工具；
第三，存储过程转换工具，能够输出你的存储过程，帮你输入，能够间接在 Java 上运行一段代码；
第四，在线换库框架，即在做完利用和数据迁徙革新之后，把流量从旧的数据库切到新的数据库。

首先是一键全自动化的数据库底层迁徙工具，它实现了从数据库的字典转换到全量同步、增量同步。增量同步这一步做完就能够了解为咱们曾经做了一个异构的实时同步的数据库，每当 Oracle 外面有数据变动，MySQL 马上就会失去实时更新好的数据，放弃实时同步的状态。之后咱们会进行全量的 Oracle 和 MySQL 的数据校验。数据校验咱们会校验到整体数据库表的行数，包含每一行、每个记录、每个字段外面的值，包含它的精度、小数点，每一位数字都要保障严格统一的状况下才满足咱们切换的条件。

整个迁徙的过程中咱们也反对数据库的迁徙革新。原来是一个库的，咱们能够在去 O 过程中从原来的 Oracle 迁到多个 MySQL 或者多个 TiDB 库下面，也能够在一个大表的状况下拆分成反对多库的分库分表的模式，同样也是能够和下面的双向同步的架构混合应用的。

第二个工具是咱们从 Oracle 到开源数据库，目前是 TiDB 和 MySQL 的 SQL 语法兼容的智能化适配转化器，当初能够基于 Java 代码的 Mybatis 的 SQLMap 文件，咱们会剖析它的文件的构造，依据外面 XML 的标签提取出 SQL 语句，通过 SQL 语句把它拆解成词素流，把每个词素进行剖析，依据 Oracle 到 MySQL 特定的转换的规定去把它转换成 MySQL 的语句，而后再填充回 Mybatis 的文件。

这个工作次要为了不便开发疾速对利用代码进行基于数据库替换的革新工作。

存储过程转换工具总体和 SQL 转换类似，也是把存储过程自身的开发语言语法解析成 AST 的语法树，而后依据这个树上的每个节点，它的元素类型和含意，转换成 Java 代码外面所操作的对象。

最初是一个流量的切换的工具。这里会有一个总开关，通过一个应用层的开关去管制以后要应用哪个版本的 SQL map，而且总开关除了管制 SQL map，还能够管制底层数据的同步流向。

在生产流量切换的工夫点，咱们会对底层数据库先同步切换，切换之后咱们会进行最初一次数据的增量比对，数据比对没问题的状况下，会把利用的开关流量间接切到新的 MySQL 数据库下面，这时候 MySQL 进来的数据会马上同步回 Oracle，如果产生一些意外情况，比方 MySQL 的执行效率忽然产生大的稳定或迁徙过程中代码革新有 bug，咱们能够马上通过开关切回 Oracle 模式。

咱们能够看到去 O 过程中大部分工作集中在数据库的迁徙，还有开发人员的 SQL 利用革新和存储过程的重构，咱们在这方面进行了相应研发，当初有两个工具能够反对咱们疾速转化，这也是整个去 O 过程中效率晋升最大的一部分。

有了这套计划，只须要做好打算，制订好每一个去 O 的业务批次。

因为咱们去 O 是依据表维度进行迁徙，所以个别会针对某一个库，依据业务模块的分工确立好批次，而后有打算地进行革新，按批次推动到线上，再进行每一批次的开关切换，这样能够缩小整个数据库流量切换的危险，保障每次切换管制都是某个业务线或者某一个功能模块的变更操作。

去 O 之前会用比拟好的设施，用 Oracle 数据库整体来撑持网站下层大部分的业务。去 O 之后，咱们次要用 X86 服务器，十分便宜，数据库是用开源的或者是国产的。

去 O 之后咱们数据库整个的服务器数量和实例数也大规模增长，底层用了本人研发的 DataBus 数据同步工具，它会把业务线写入的数据实时同步到咱们后端剖析型数据库存储引擎下面，像 ES、TiDB、Hbase、Clickhouse 都会有。因为原来在 Oracle 的一个大库上面做些关联查问、统计计算比拟不便，但去 O 之后这么多数据扩散在那么多实例外面，要做这方面的关联查问就须要借助智能架构。

对于去 O 的收益总结如下：