作者简介：
gaosf，携程高级开发经理。
携程金融是携程集团旗下的金融服务平台，成立于 2016 年，依托于数字科技能力，为用户提供便捷的旅游金融服务，包括旅游分期消费、小微企业主金融等多款产品，方便用户在旅游消费时获得资金支持。
作为保证携程金融业务的基础研发部门，我们在 2024 年上半年落地了一个基于 OBKV 千亿级指标数据存储方案的实践。本文从项目背景、项目方案、项目成果这三个方面分享项目过程及经验。
在金融场景下，需要依赖用户指标数据做一些核心业务逻辑的决策，比如风险决策、个性化服务等，而这些数据都是纯 KV 对的形式。数据由大数据平台产出，通过离线计算任务的方式生成，落到 Hive 表中，之后将数据从 Hive 表再导入 MySQL 等存储引擎中，供业务进行实时调用。
总体数据规模在几千亿+KV 对，采用增量更新的方式，每天的更新规模为数百亿个 KV 对。
部门几乎所有的核心业务系统都依赖于这项服务，业务方对我们提出了两个诉求：
💡 针对写入，要尽可能快，尤其是高优任务 2 小时内写入完成，所有写入任务不允许超过 24 小时。
💡 针对查询，要求在 50ms 内完成，查询耗时越短越好。
因此我们需要一个能够支持快速写入且查询性能稳定的 KV 存储方案。
起初（2016~2019年），我们使用 HBase 存储，因为 GC 停顿等问题，无法满足业务查询性能的需要。2020年，我们开发了一套 MySQL 存储方案，查询性能满足要求，并且稳定运行了近 4 年。
2023 年新需求上线，需要写入的数据量翻倍，单表数据总量达到 300 亿个 KV 对，每日例行更新的数据峰值达到 500 亿，且类似这样的业务需求还在增加。此时 MySQL 方案写入能力已经到达上限，扩容也比较困难，且 IT 成本较高，于是开始了新一代 KV 存储方案的探索。
2024 年初，我们开始了整个应用架构改造和存储方案的探索和引入。
1、应用架构改造
🚩 将存储引擎进行业务层抽象，以便快速接入新的存储引擎。
🚩 对数据消费队列改进，将基于 Kafka 的消费队列改为基于文件的消费队列，以便对导入任务进行灵活的暂停、续写、重试、终止等控制。
🚩 自研了轻量级的任务调动框架，以实现对数据导入任务进行全生命周期的管理，如通过 API 进行任务的启停、依赖配置、优先级动态调整等。
最终，在应用侧，可同时引入多种存储引擎，且各个引擎间读写相互隔离，实现了存储引擎的快速、低成本的扩展接入，并且有比较灵活的运维能力。
2、存储引擎探索
在存储方面，我们需要存储容量可动态扩展，写入性能高，至少满足历史峰值需求（500 亿 KV/天），查询要快且稳定。
2024 年 7 月，我们将 OBKV 快速接入系统。下图是我们在生产环境中的验证结果，并和此前的 MySQL 方案进行了对比，结果如下：
针对我们的场景，将“每分钟能写入的 KV 对数量”作为业务侧的一个重要衡量指标。
在使用 MySQL 存储方案时，部署了 64 个节点，采用分库分表方案，写入速度（仅写入）的历史最大值达到 6000w (KV 对)/min（连续运行 1 小时后，Server CPU 告警），读写都开启且不影响查询的状态下写入速度是 2000w (KV 对)/min（连续运行 24 小时后，Server CPU 告警）。
上线 OBKV 后，部署了一个 9 节点的集群，为了探索写入能力上限，在不考虑读性能的前提下，最大的写入速度达到 9600w (KV 对)/min，不影响查询性能的前提下可以达到 6000w (KV 对)/min的写入速度。
在响应时间方面：在同等条件下，OBKV 批量写入速度是 1.3w/s，批量查询速度 1.8w/s；由于 MySQL 的分库分区方式，导致批量写入和批量查询的数据相差较大，分别是 5300/s、41.7w/s。在响应时间方面，OBKV 写入的平均速度是 15ms，P99 能够达到 20ms，查询响应时间平均 3ms，P99 是 10ms；MySQL 写入比较吃力，达到 900ms，查询的性能与 OBKV 相差不大。
在稳定性方面： OBKV 写入限流 6000w/min，连续写入 24 小时，查询没有任何波动，而 MySQL 在写入速度超过 3000w/min 后，查询时间飙升。
在存储空间层面：在单副本维度，全量数据 OBKV 的空间占用是 MySQL 的 1/5。
3、OBKV 双集群部署
OBKV 于我们而言是一个比较新的产品，在携程集团内部也是首次引入，相关的运维经验缺乏。可 MySQL 方案已经无法很好支撑业务需求，能尽快把 OBKV 用起来。
综合考虑下，在业务层又设计了一套双机房部署方案，来尽可能增加可靠性。核心思路是两个对等的机房进行双写，任何一个集群单次写入失败，都使两个集群重试，来保证两个集群间数据的一致性。在查询时，优先查询同机房的集群，超过指定时间（如 20ms）后降级查询另外的机房。
该方案的优势在于：
✅ 在成本可控范围内，最大化提升整个服务的可靠性。因为 OBKV 集群只需要 9 个节点，即使部署两份集群，节点数也远远少于 MySQL 单个集群，从成本角度考虑完全可以接受。
✅ 可以减少 DBA 的运维压力。DBA 进行单集群的运维、增删节点、更换磁盘或进行其他的操作都可以直接进行，整体服务不会受到影响，为 DBA 进行后续 OBKV 性能调优、运维预留了充分的探索空间。
自 2024 年 7 月 17 日起，OBKV 在携程金融生产环境正式应用，已稳定运行至今。原来在 MySQL 的流量 100% 切换至 OBKV，取得的成效显著。
🚀 写入性能优秀：限流 6000w/min，每天可写入 864 亿数据，远高于业务需求的 500 亿，高优任务 2 小时完成率从 60% 提升到了近 100%。
🚀 查询性能稳定：限流的上限持续写入，查询无明显波动，p99 约 10ms，p999 低于 30ms 几乎维持在 15-20ms。针对查询和写入性能，未来也可以通过集群扩容进一步提升性能。
🚀 存储成本骤降：OBKV 和 MySQL 的数据压缩比为 1:5，存储总空间降低 72%，硬件成本降低近 60%。
🚀 应用架构精简：得益于 OBKV 天然的分布式能力，我们无需处理复杂的分库分表逻辑，应用逻辑被极大简化，换算成应用的机器数量也极大减少，应用 CPU 核数精简了 50%。
本次数据存储方案探索较为成功，感谢 OceanBase 开源团队和 OBKV 团队在我们项目落地的过程中全力支持。
往期推荐
▼ 点击「阅读原文」，了解更多客户故事
