性能提升 5 倍！翼支付基于多租户的降本增效实践

作者：王硕 中国电信翼支付 DBA

翼支付是天翼电子商务有限公司旗下第三方服务平台，面向 7000 万月活用户，提供民生缴费、消费购物、金融理财等服务内容，依托云计算、大数据、人工智能等技术，联合合作伙伴，赋能超 1000 万家线下商户门店及 170 余家线上知名电商。

作为拥有千万月活用户的服务平台，翼支付与生活息息相关，其业务不仅种类繁多且复杂，与此同时需要对相关数据进行存储和处理，当前的数据库方案出现存储空间吃紧、分析实时性差、成本难以掌控、运维难度增大等问题，亟需选型和替换架构以保证业务长期的稳定运行。

在此大背景下，翼支付深入调研分析了市面已有的分布式数据库方案，最终将 OceanBase 作为首选方案。

该方案在真实场景测试和验证后，性能方面较旧方案提升 5 倍，硬件成本下降 57%，存储空间节省 10%，机器成本与运维成本极大降低。于是决定将消息中心、账单中心等业务由某国产数据库替换成 OceanBase ，同时将已有的 MySQL 业务逐渐迁移至新方案。

挑战：实际使用面临多个难题

在早期的数据库方案中，某国产数据库主要应用于账单中心、征信及反洗钱等业务场景并发挥了重要作用。随着月活用户量的不断增加，相关联的业务也在不断增长，在实际使用中遇到以下 3 个主要问题。

一、租户不隔离

由于我们在某国产数据库集群中放置了很多库，因此多个库之间共享集群资源，在某些库对应的业务流量高峰期时，业务之间互相影响，严重影响使用体验。

二、硬件成本高

在运维过程中，为了保障业务的稳定性，避免不同业务之间互相影响，通常对业务进行物理隔离，即不同的业务使用不同的数据库环境，因此多套业务对应多套数据库环境。也就是说，为了保证业务的稳定性，一个业务一套集群且集群的每个角色都配备一台机器，以账单中心和消息中心为例，原有的方案需要分别部署数据库环境且一套数据库环境即需要消耗 7 台机器，共需要 14 台机器。虽然业务之间做到了隔离，但是成本昂贵，性价比不高。

三、稳定性不够好

以消息中心业务为例，测试中发现某些在某国产数据库中查询较慢且出现秒级别尖刺，业务不定期出现抖动现象。

考虑到公司业务大多已采用两地三中心部署方案，业务层面也应用了双活架构，对比市面上的分布式数据库，OceanBase 正好提供两地三中心部署，并且每个中心都可以提供业务访问，完美契合了当前公司的业务架构。

选型：敲定 OceanBase

此外，作为国内典型的分布式方案，OceanBase 具有原生分布式架构，支持金融级高可用、透明水平扩展、分布式事务、多租户和语法兼容等企业级特性。此外，从性能、成本、稳定性等方面来看都能满足公司需求。

性能上：每个节点都具备计算和存储能力，当业务计算要求增加或者数据量快速增长时，通过增加节点来扩展计算和存储能力，同时一体化架构使得分布式集群组件之间和组件内部 RPC（Remote procedure call）消耗更少，业务访问尽可能本地完成，减少不必要的 RPC 交互，性能更好。在实际测试中，我们发现通过增加硬件资源，集群的性能线性增长，符合预期。

成本上：在业务使用中，使用租户隔离特性非常便捷地将多个业务放在一套或极少数量的环境进行运维，加上官方配套的运维管控平台 OCP 、数据迁移工具 OMS  等等生态工具，使得运维复杂度极大地降低。在实际测试中，我们发现在硬件层面，相比其他数据库方案，OceanBase  资源消耗更少。综合评估下来，使用 OceanBase  成本更低。

稳定性上：业务表对应的数据在底层以多个数据分片形式存在，在分布式架构下，单表的数据可以均衡分布在不同的节点，不需要复杂的分库分表方案；同时在底层数据存储时，数据存储多份（默认三副本）同时引入多数派 paxos 选举协议，在集群少数节点或者副本故障、异常时，确保上层业务不会受到影响，同时业务数据不丢失。

图 1 OceanBase  典型三副本架构

这三个特性是当前业务最需要、最看重的能力，因此，OceanBase 数据库成为了解决我们业务问题的首选方案。

业务双写验证测试结果超预期

在确定选型方案后，我们对 OceanBase  3.1.4 版本与某国产数据库进行各方面的对比。在实际环境中，对业务进行了简单改造，采用业务双写的方式验证对比某国产数据库与 OceanBase 方案。测试结果超出我们的预期：

第一，硬件成本下降 57%，同时资源消耗显著降低。OceanBase 的多租户特性具备资源隔离的能力，因此我们将账单中心和消息中心业务迁移至 OceanBase 环境，并使用多租户能力分别创建业务租户，机器资源从原来的 14 台机器变为 6 台，硬件成本降低 57%，同时多套业务集中在一套环境运维，日常管理更加方便。

在 CPU  使用率方面，账单中心和消息中心在某国产数据库环境中，CPU 平均使用率 20%-25%，在 OceanBase 环境中， CPU 使用率为 5% 左右；在存储空间上，某国产数据库需要占用 19TB  的空间，OceanBase 的存储空间占用为 17TB ，节省空间约 10%。同等业务量下，OceanBase  方案资源消耗更少。

第二，性能提升 5 倍，单表分析能力提升 10%-20%。在消息中心业务中，某国产数据库消息状态更新接口耗时平均在 10ms ，同等条件下 OceanBase 使用分区键的响应 latency 持续稳定在 2ms ，响应时间更短且稳定。另外，线上的账单业务有一个 200 亿大表，在 hash 分区策略下，OceanBase 单表分析能力较某国产数据库提升了 10%-20%，

第三，极大减少运维成本。在数据库集群管理方面，借助 OceanBase 提供的 OCP 白屏管理工具，OceanBase 集群能够实现统一管理，我们的 DBA 可以直接登录 OCP 平台对所有集群进行日常操作与维护，管理界面如图 2 所示，减少了大量的管理成本。

图 2 OCP 集群管理界面

除日常运维管理能力外，OCP 也提供了对集群的监控和告警服务，如图 3 所示，我们可以直接从 OCP 页面看到各个集群的运行状态，在出现异常的时候发出报警。

图 3 OCP 监控界面

当前我们的业务环境中 OceanBase 已经支持了消息中心、账单中心等业务服务。结算中心、反洗钱业务后续会全部迁移至 OceanBase 。

经验总结

对于此次的数据库技术方案选型以及实际使用效果反馈，总体来说让我们有些出乎意料。我们将此次选型成功的重要因素和经验总结为以下 3 点，供大家参考。

第一、业务平滑迁移

通常在数据库迁移过程中，我们最关心的问题就是如何保证"服务不停、数据不丢"的同时最大化降低数据迁移的时间和成本。我们使用 OMS 平滑、准确、高效地解决了 MySQL 环境迁移数据的问题，降低了业务迁移成本，同时兼容性方面做到应用不需要修改即可完成迁移。比如，在某国产数据库迁移中，我们选择使用某国产数据库的 Binlog  工具来完成某国产数据库到 OceanBase 的数据平滑迁移。

第二、统一平台管理，提升运维效率

OceanBase 环境使用一套 OCP 环境管理，不需要单独对每一套环境进行运维和管理，帮助运维人员便捷地进行环境管理和运维工作，同时其自带的监控和告警系统大大提高了问题发现的实效性，使问题能够更加高效、快捷的被解决。

第三、多租户能力及资源隔离优势明显

在实际使用中如商城业务会分很多库，为了避免这些库之间资源发生争抢从而导致其他库无法正常运行，将库按租户进行分离，利用租户的资源隔离能力，限制每个库的使用资源额度。并且，租户资源可以灵活调整，所以，每个库的资源也可以动态调整，从而保证业务的稳定性和灵活性。

以上就是翼支付的数据库技术方案选型过程及感受，希望能对正在考虑数据库选型的朋友一些提供参考价值。