国内首家完成生产环境分布式数据库上线的期货交易所

1. 传统集中式数据库已经无法满足多项需求
   1. ​传统的集中式数据库架构支持一般业务系统时，可以做到高效、稳定和可靠，对金融服务的发展起着重要支撑作用，但并不能较好适应数字经济时代金融业的高并发、大流量、高可用的特征。随业务系统数量的快速增长，传统集中式数据库已经无法满足郑商所的多项需求。
2. 分布式数据库转型挑战
   1. ​分布式数据库架构的核心理念按照一定维度将系统进行拆分，通过开放的结构，实现各业务模块松耦合，降低对底层硬件的依赖程度。然而，从传统集中式数据库转型分布式数据库，对业务开发和数据库运维都是很大的挑战，同时借助分布式数据库转型的机会如何提高容灾等级也是一大考验。

▍ 开发方面

分布式数据库在兼容性方面需要尽量兼容传统数据库（Oracle/MySQL）。业务从 Oracle/MySQL 迁移至分布式数据库时，需要尽可能地减少业务SQL改造，降低业务开发的学习和分析成本。兼容性还包含数据库访问驱动接口的兼容（如 JDBC、OCI 等）。除兼容复杂 SQL 外，性能方面也不能有问题。分布式数据库要能证明自己在复杂业务场景和复杂 SQL 方面的性能。

▍ 业务方面

在迁移至分布式数据库时，存量数据也需要迁移，且迁移过程必须在线，而且还要保证迁移数据的正确性和时效性。郑商所的期货交易业务覆盖全球，业务允许的割接停机时间非常短，业务的服务需求需要保证 SLA，数据库的可用性也必须做到在业务的 SLA 范围以内。

▍ 运维方面

分布式数据库多是 Shared-Nothing 架构，部署在普通的商用服务器上。相比传统小机存储，会给运维带来两个难题：一是数据库服务器的数量会比较大，二是数据库服务器的可用性没有小机那么高（即服务器故障率相对高一些）。因此，运维管理分布式数据库的工作量可能会增加，并且分布式数据库的故障率可能会相对比较高。这就对分布式数据库的运维提出更高的要求——规模化、自动化；也给分布式数据库的稳定性提出更高的要求——高可用、不丢数据；同时，分布式数据库的扩容缩容操作要求能在线进行，并且尽可能自动化。

1. 高度兼容
   1. ​OceanBase 分布式数据库提供的高度兼容 Oracle 语法的租户和配套迁移工具，可以便捷地将之前运行在 Oracle 上的系统业务，下移至基于 OceanBase 分布式数据库的开放平台上，并且提供与 Oracle 接近的功能和性能。
2. 平滑迁移
   1. ​OceanBase 提供了一站式数据库迁移解决方案，包括迁移可行性评估、迁移成本评估、迁移性能评估、结构对象迁移、数据迁移、数据校验和反向增量同步保护等完整的在线迁移割接能力。OMS（OceanBase Migration Service，OceanBase 数据迁移工具）的数据校验功能，为郑商所提供源数据库和目标库的全列数据一致性校验能力，保障数据迁移质量。同时，反向链路的数据同步为无损回滚能力提供保证，确保业务的连续性不受影响。
3. 多租户架构DBaaS 平台
   1. ​郑商所基于 OceanBase 的多租户架构，打造了属于自己的 DBaaS 平台，将多个不同业务的数据库实例集中整合，不仅提升资源利用率，同时基于 Paxos 的多副本机制可以保证每个资源单元的高可用能力。

郑商所在行业内率先在生产系统上线分布式数据库 OceanBase 集群，验证了 WEB 服务类和 C++ 语言模式下的高性能应用系统的数据库迁移路线，并且充分利用分布式数据库的技术特点，提升数据库的容灾备份能力，并简化了变更升级操作流程，真正享受微服务架构带来的便利，提升系统连续服务能力。

1. 更低的改造成本，享受分布式架构的技术红利
   1. ​在业务代码基本不做改动的前提下，通过分布式数据库自身语法兼容性的能力，结合分区、多租户等特性，郑商所的业务系统能够以更低的改造成本得到分布式架构的技术红利，降低迁移成本、迁移风险的同时，为更多业务系统的快速迁移适配打好基础。
2. 在线迁移割接，保障相关业务系统平稳运行
   1. ​在整个迁移过程中，OMS 支持在全量数据迁移过程中动态调整并发度，只会占用源端极少量的 CPU 和存储 I/O，对源端数据库和在线业务的影响极小，保证了在数据迁移过程中，期货交易系统的平稳运行。
3. 高效运维，降低数据库总拥有成本
   1. ​通过多租户打造的DBaaS 平台，郑商所将内部大量不同业务链路的资源池化，为不同业务系统提供不同规格的实例，保证资源隔离性的同时大幅降低数据库总拥有成本（TCO）
4. 真正做到“先恢复，后排查分析”
   1. ​郑商所有了 OceanBase 智能运维体系的全面保障护航，常见的 SQL 问题、诊断等可以自动实时分析，给出合理的应急优化建议。并且能够有效解决因宕机、网络抖动、大查询等造成影响生产连续性的问题，真正做到“先恢复，后排查分析”。