作者简介：曾祥勇，云集电商 DBA
云集电商是传统电商公司，成立四年后便在纳斯达克上市。但与京东、淘宝、拼多多等业务模式不同的是，云集电商基于社群，是社交驱动的会员电商平台，主要的服务商为 B 端。
目前，云集电商的业务线主要有美妆个护、服饰、水果生鲜、健康保健，依托于两大系统为会员提供服务，分别是云集（App、小程序）、云集健康（小程序）。
一、电商行业数据库需求分析
与传统的互联网企业系统相比，电商企业最大的特点是经常举办大促、秒杀活动，带来的瞬时高并发流量与高 QPS 对服务资源的要求极高。此外，在选品及推送、运营分析、财务数据分析、报表分析等方面需要大数据计算与分析。
因此，云集电商对数据库的需求首先是稳定性、高可用，其次是应对大促、秒杀场景的扩缩容能力，以及一些通用特性如高性能、高兼容、多中心部署、低成本、安全。
此外，架构随着业务的发展逐渐变得复杂后，数据需要流转到大数据侧进行分析、计算后再传输回来，虽然数据算不上庞大，但过程也需要维护。我们希望能有一款支持 HTAP 场景的数据库来降低数据处理与分析的复杂性。
二、云集电商应用分布式数据库历程
在云集电商成立初期，所有业务都搭载在 MySQL 数据库之上。不久，疯狂增长的交易量使财务数据、对账数据迅速膨胀，而 MySQL 的性能、扩展能力与应对批量数量处理的能力有限，经过我们 DBA 团队和开发团队的一致讨论，决定引入分布式数据库来支撑业务需求。
由于云集电商是在阿里云上，所以选取了阿里云生态中的 HybridDB，基本可以满足当时的业务需求。后续因为战略调整，从阿里云迁移至腾讯云，但腾讯云上没有可用的分布式数据库，经过调研，选用某数据库作为归档库，应用于边缘业务中。这时云集电商已完全弃用了 HybridDB，业务主要使用 MySQL数据库，对帐数据库使用某数据库。
2020 年到 2023 年，云集电商的业务量逐渐下降，成本压力成为我们首要解决的问题。彼时，我们使用腾讯云的 CDB，业务微服务的架构导致 MySQL 实例 1000+ ，CVM 高峰期，实例接近 3000 个。针对每一个微服务的数据库实例，会有基础的一主一从，另外还会有一个用户从库，一个系统对应三个数据库实例。
同时，业务数据库通过 Flink、Canal 等组件输出到大数据进行统计分析，生成 T+0、T+1 的报表。再将分析数据同步回业务数据库，供用户查询，形成数据的循环。
复杂的业务架构与多实例带来的运营成本，使云集电商数据库系统难堪重负，亟需优化。
同时，在使用某数据库的过程中也存在一些问题，比如扩容后性能提升达不到预期，而且一些参数调整需要重启集群，有时候个别节点会启动失败。因此，出于稳定性考虑，我们没有将某数据库用于核心业务，因此在成本优化之际，便舍弃了这个产品。
机缘巧合下，我们接触到了 OceanBase，发现其特性更符合我们的战略需求，主要有以下几个方面：
✅ 稳定性强，可持续响应服务，保证整体业务的稳定。
✅ 兼容性高，简化新技术和架构的应用，降低开发难度，减少学习成本。
✅ 低成本，极致的数据压缩带来存储成本优化。
✅ 高可用，多地多中心部署，容灾有保障。
✅ 不过度优化，可避免因过度优化降低业务的波动能力。
✅ OceanBase 的吞吐量和生态系统的支持良好。
✅ 一体化的 HTAP 能力可满足业务高峰交易场景和分析场景的业务需求，极大简化原有架构。
✅ 水平扩展方便，资源利用灵活，同时可以解决大促场景中 MySQL 扩容切换导致的业务中断问题。
上文提到，我们最看重数据库的稳定性，而 OceanBase 的稳定性在业界闻名，因此，我们开始初步试用。
三、云集数据库迁移与成效分析
目前，我们已经将 30+ 个业务迁移到了 OceanBase 数据库，包括社群系统、供应链、农场项目及其他业务，并且在规划迁移更核心的业务场景，订单系统，预计 2025 年迁移完成。
下文以其中的农场项目为例，讲述迁移过程及收益，并分享其中的经验供大家参考。
农场项目共有 6 台主实例，数据量 13TB 左右，由于是在线业务，在迁移时要求不影响线上用户的使用，最好对业务无感知。同时，我们也希望不需要开发人员改动代码就能实现平滑迁移。另外，考虑到我们的业务生态、中间件如 Canal、Flink CDC 等兼容性，还要求新的数据库 OceanBase 能够兼容。
明确的需求可以使迁移评估更加高效，基于上述要求，我们做了 5 项评估，分别是：
👉 中间件收集及版本检查，用于判断新数据库是否支持；
👉 检查帐号及连接 IP 等，收集业务访问，以便根据业务情况制定合适的迁移策略；
👉 查询新数据库中是否有定义函数，存储过程，触发器及字符集等，对于我们而言是禁用的，因为容易引发问题；
👉 迁移前处理慢 SQL，进行资源评估，预估 MySQL 数据量迁移后的占用情况；
👉 评估总体兼容性和性能。
我们选择 OceanBase 的迁移工具 OMS 完成数据迁移和同步。OMS 支持多种数据源，可以在线不停服进行迁移，性能也不错，还会进行多重数据校验，其原理如下图所示：
具体的迁移步骤分为六步：
第一步即上文提到的业务检查。第二步做迁移准备，包括慢 SQL 及数据归档、字符集检查、资源评估、迁移测试链路等，其中如果发现了不支持的字符集，需要在迁移前转换，以保证迁移过程的稳定性。第三步是配置迁移任务，比如创建帐号、配置数据源、配置迁移链路、反向增量同步。第四步是数据同步，并监视此过程。第五步确认迁移结果，选择一个流量较少的时间段将业务重启，切换数据源。
迁移完成后，会涉及收尾工作，也是第六步。对于云集电商而言，为了减少迁移的复杂性，从 MySQL 到 OceanBase 按表迁移，然后再做合库合表，因此，迁移完成后我们涉及同步连接关闭、资源释放、业务改造等收尾工作。在此过程中，我们也发现 OMS 每次同步的表数量有限，大约 3000 个表。同时，也遇到了使用 OBLogProxy 时内存泄露的问题，不过 OceanBase 官方人员介入迅速修复了该问题。
四、总结
目前，我们已经迁移 30+ 业务，40+ MySQL 实例，我们最看重的成本优化效果超出预期，服务器成本降低约 45%，数据压缩率提高 43%。在此之前，某些业务的数据量已经突破了单机容量的上线，迁移到 OceanBase 后，受益于其极致的压缩率，这个问题也顺利解决。
在不久的将来，业务全部迁移完成后，得益于 OceanBase 的诸多特性，我们预估效果如下：
🚩 一体化 HTAP 的运用使得数据不再需要流转（ETL），直接当成数据仓库使用，极大地降低架构复杂度。
🚩 多中心的部署方案直接满足等保需求，并借助多中心部署方案满足多活能力。
对于企业而言，数据库升级就像心脏移植，充满未知与风险，因此，我们需要做好充足的产品选型与调研工作。对于云集电商而言，从 MySQL 到 HybridDB，再到边缘业务试用某数据库，再到如今将大量业务迁移到 OceanBase，经历了些许坎坷。
