浅析OceanBase 在高德金融场景的业务落地

自从高德与OceanBase展开合作以来，二者的业务动态一直备受业内人士的关注，更有不少企业希望能从这场合作中找寻到自己可以借鉴的成功范本。

不过，OceanBase在高德业务场景中的落地成果究竟怎么样？或许从其金融场景业务的案例中，我们可以窥见一二。

高德 359 行财务结算服务主要服务于高德信息业务的结算和财务数据，主要诉求是要求数据强一致性，保障数据不丢失，跨地域容灾能力。

具体来看，首先财务结算服务作为与 B 端商家合作的钱款计算的一环，对数据一致性有极高的要求，不能出现因数据不一致或最终一致而导致钱款计算错误的情况。其次，财务结算服务业务逻辑复杂，需要降低迁移改造成本，最好能完整兼容原业务所使用的 SQL 协议，平滑替换底层数据库，不需要业务过多的改造。

而针对以上诉求，OceanBase具有哪些解决优势？

首先，针对财务需要数据的强一致性和跨地域容灾，OceanBase可以提供的能力完美支持该需求，其提供的跨地域部署的能力，可使得财务数据同时写入多地域的数据副本中，即使一地域不可用后仍然能保证有完整的数据可用。并且 OceanBase 的 Paxos 一致性协议可保证 OceanBase 多副本数据写入成功后才应答成功，为分布式多副本数据的强一致提供了保证。

其次，为了验证和解决 SQL 兼容问题，未使用 OceanBase 提供的 OceanBase Client 去访问 OceanBase，而是使用原生的 MySQL 数据库 的SDK 驱动，通过 MySQL 驱动访问 OceanBase，在 OceanBase 上回放财务全量 SQL 并验证通过。

再者，为了降低财务结算系统改造量，将 OceanBase 的表按不同的功能进行建设，将原有分库分表的设计逻辑应用到 OceanBase 分区表的分区键设计上，以便上层业务可透明的切换数据源。对于数据量比较稳定的维表数据，比如合同数据等，将其建设为单表，避免全局分布式事务，提高频繁查询的性能。

因此，高德最后选择了OceanBase三机房的部署架构，通过使用 OMS 进行数据迁移，数据一致性的校验通过使用集团的 MAC 系统来核对，而实时的数据写入不一致问题通过监控方式报警处理。

同时，因财务结算非 C 端业务，核心关注是数据的强一致型和跨地域容灾型。并在平衡成本后，在 OceanBase 的同城三机房、两地三中心和三地五中心的部署方案中选择使用同城三机房的部署方案，既可以实现财务结算的数据一致性和跨地域容灾的目标，也能一定程度上节省成本，后续有需要也可以快速升级为三地五中心部署。

在完全切换 OceanBase 前，XDB 和 OceanBase 都有全量的业务数据，并可通过 MAC 每天进行全量数据核对，同时对于增量数据不一致情况及时报警处理。同时又因为 XDB 和 OceanBase 都保有全量数据，因此一旦切流遇到问题，可通过开关一键回切原 XDB 数据库。

得益于OceanBase的介入，如今高德 359 行财务结算服务的存储稳定性、高可用和容灾能力以及跨地域级别的容灾能力得到了大幅提升。

同时，结算财务类的数据也保障了较高的一致性，而非用最终一致性的妥协换取其他方面的能力；数据库弹性扩缩容的能力提升，存储横向扩展对上层系统透明，极大降低数据迁移的风险；减少数据占用的存储容量，OceanBase 使用的 LSM-tree 结构存储最大可压缩数据至原大小的 35%，降低存储费用成本。

此外，迁移 OceanBase 后仍然可使用 MySQL 原生驱动，使用 MySQL 5.7 版本的 SQL 进行业务功能开发，兼容原有存储(XDB)的协议，极大降低业务系统改造成本。

最后整理压测结果显示，压测数据写流量在 4K 左右，RT 稳定在 1ms 左右。

综合来说，OceanBase的高可用、可扩展、高性能、低成本等核心特性，为高德金融业务的发展提供了更好的性能和更低成本。可以预见的是，随着OceanBase在高德更多业务场景落地，将为高德在深入市场发展的过程中提供更强的竞争力。