OceanBase赋能百丽核心系统上线，护航双11流量洪峰

黄尖百丽时尚数据库专家

百丽时尚集团（以下简称“百丽”）作为中国领先的鞋服零售巨头，构建了覆盖300余城、超9000家直营门店的立体化零售网络。其独创的垂直一体化运营模式，深度融合消费者洞察与数字化技术，构建起从时尚潮流研究、商品企划、设计研发、生产制造、商品管理、DTC 零售及客户运营的全价值链，且每个步骤运用数字化技术，并将持续加强科技投入。面对早期零售、商品管理及私域运营等多业务线并发的复杂场景，传统MySQL+MyCAT分库分表架构渐显疲态。该架构在应对业务快速迭代时暴露三大痛点：数据分片策略僵化导致业务调整成本高昂，横向扩展能力受限制约增长潜力，以及高并发场景下性能波动影响用户体验。为突破技术瓶颈，百丽启动数据库架构升级战略，将目光投向具备原生分布式能力的解决方案。

当前，OceanBase已全面承载百丽订单中心、消息中枢等核心业务系统，构建起稳如磐石的技术底座。在日均海量交易处理的常态化考验之外，更在双11等流量洪峰期间展现出卓越表现：通过分布式架构的弹性扩展能力，系统成功抵御瞬时流量冲击，实现核心业务”零故障”运行，为百丽数字化转型提供了坚实的技术保障，充分验证了新一代数据库在复杂零售场景下的商业价值。

一、MyCAT使用痛点及分布式数据库选型

MyCAT 是一个开源的分布式数据库中间件，主要用于解决单机 MySQL 处理大规模数据和高并发访问时的性能瓶颈。百丽的业务系统普遍使用了 MySQL+MyCAT 的分库分表架构设计。尽管 MyCAT 在过去一直支撑着百丽的业务发展，并在某些场景下发挥了重要作用，但随着数据量日益增长和业务场景逐渐多样性，其不足开始显露。以下是百丽使用 MyCAT 时面临的常见问题。

（一）聚合性能不稳定

在 MyCAT+MySQL 分库分表的架构下，MyCAT 作为分布式中间件，在聚合查询场景下，尤其是在多个分片的数据聚合方面，性能容易抖动。MySQL 多个分片查询到数据需要汇总到 MyCAT 之后再进行统一聚合，最终返回结果，在大数据量需要聚合的场景下，性能下降比较明显。

（二）数据分片调整困难

在日常运维的过程中，经常会面临一些业务调整需求的情况，而 MySQL 的分库分表架构调整起来非常困难。一方面会涉及数据的重分布，另一方面是 DBA 实操的复杂度较高且非常繁重。

（三）水平扩容较差

受制于原生 MySQL 数据库的原因，现有架构不能进行水平扩容，无法满足不断增长的数据处理需求。

（四）硬件成本高昂

MySQL 主从+ MyCAT 分片的架构配置动辄需要几十台服务器，给企业带来了高昂的 IT 成本，不符合当前降本增效的时代背景和业务需求。

在新架构的选型过程中，我们发现 OceanBase 可以解决上述问题。

🚀 OceanBase 作为原生分布式数据库从根本上避免了聚合性能不稳定的问题。在生产系统 MyCAT 聚合需要 10 分钟一条 bad SQL，使用 OceanBase 进行测试数据聚合只需要 1 分钟左右，性能提升了 10 倍。🚀 在 OceanBase 中，当业务分片需要调整时，只需要调整表分区，OceanBase 会自动对分区做重分布操作，操作非常简洁、迅速，极大地减少了 DBA 的整体工作量。

🚀 OceanBase 可以根据业务的实际需求和实际情况，灵活选择水平扩容或垂直扩容。比如可以水平做租户资源，或者在集群级别添加 OBServer 节点；再比如扩容磁盘，我们数据盘的使用率较高，对磁盘扩容后，数据文件也会自动扩展。

🚀 得益于 OceanBase 优秀的存储压缩性能，生产环境数据同步到 OceanBase 后，所需的存储减少到原先 MySQL 的 1/3 以上。

二、业务架构优化之高可用设计

基于选型结果，我们的订单中心应用率先上线了 OceanBase 数据库，上线流程如下图所示。

订单中心系统是百丽电商系统中的核心系统，通过统一管理和配置所有渠道电商订单，实现订单业务的标准化、通用化、配置化，以及统一全渠道订单业务数据，提供更加准确、全面和标准化的数据来源。为了保证上线顺利，以及上线后的效果符合预期，我们做了大量的准备工作，包括：

🚩 提前上线数据库管理平台，从 MySQL 切换到 OceanBase，测试各种运维场景操作和 MySQL 兼容性。🚩 在边缘业务使用 OceanBase 观测运行情况，并积累运维经验。

🚩 上线核心业务前进行灰度压测。

🚩 针对重点业务场景进行演练，如“618”大促实战演练、“双 11”预案准备及全链路演练、逃生方案演练，演练内容覆盖大促预估的订单量。

同时，优化高可用设计、强化监控及故障预案，进一步保证系统的稳定与性能的提升。对于高可用设计的优化，我们结合业务准备了灰度的切换方案，将旧的订单系统业务按照店铺的维度切换到新的订单中心系统。为此，在上线规划中，我们首先在内部使用的数据库管理平台上线 OceanBase 并试点运行，确认 OceanBase 能满足业务需求后，开始逐步从试点店铺切换到正式店铺。

在逃生方案的选择上，通过高可用部署的 OMS 将 OceanBase 的变更实时下发到 Kafka，通过业务系统对 Kafka 的监听，并对数据进行业务组装后写入旧系统数据库，通过新旧系统的并行运行和灰度切换，保证在新系统出现问题时可以无缝切换到原来的订单系统。通过数据库和应用数据同步的双边监控，实现整个同步逃生方案的可控性。

在“双 11”实践中，通过应用的双轨运行，保证业务在 OceanBase 和 RDS 之间无缝切换，通过业务间的拆分，拉单业务等所有写入的业务迁移到 OceanBase，而订单售后等部分查询业务保留在原来 RDS 上，通过 OceanBase 到 RDS 的同步保证双边数据一致，在任何一边出现问题时都能无缝切换。

目前订单中心使用 OceanBase 的系统架构如下：

在数据库架构设计的过程中，我们也做了许多工作。首先，为了降低单个 OBProxy 的负载，增加系统的并发处理能力，使用 LVS 代理 OBProxy 节点的 IP，以实现所有 OBProxy 节点的负载均衡。

其次，和零售等有明确大区信息的业务不同，电商业务没有明确的分区字段，使用用户 ID 不能很好地分散负载，因此，我们设置 Primary Zone 为 Zone1;Zone2,Zone3，把主副本都集中到单个 Zone，尽可能地避免分布式事务。

最后，由于 OBProxy 的部署通常有集中部署、独立部署和客户端部署三种方式，为了提高性能并减少对应用的影响，我们把 OBProxy 和 OBServer 部署在同一台服务器上，减少 OBProxy 路由时的 RPC 请求时间。

自 OceanBase 上线后，我们发现，相较于原来的数据库架构，存储成本下降为原来的 1/3。另外，OceanBase 丰富的生态工具体系使我们的运维工作大幅简化，比如 OceanBase 的运维平台 OCP 提供了一系列管理和运维操作的功能，支持备份管理、监控管理和 TOP SQL 等管理展示，在一定程度上实现了运维自动化，降低了运维成本；再比如 obdiag 提供了一系列诊断功能，使故障定位的时间被大幅缩短，我们可以使用闪回技术处理数据恢复案例，相对于 MySQL 只能分析 Binlog 回滚的方式，显著提高了故障处理效率。

三、“双11”大促场景性能调优方案

电商行业中“双 11”大促是对业务和技术架构的一次考验，此前使用 MySQL 总是遇到瓶颈，具体表现在高并发、扩展性、复杂查询等方面。

👉 高并发读写压力：在大促期间，大量用户同时进行商品查询、下单等操作，导致 MySQL 面临大量的并发读写压力且无法弹性扩展。👉 扩容能力较差：大促期间的数据增长快速，受制于集中式数据库的特性，MySQL 扩容操作繁琐且复杂，面临一定的业务侵入风险。

👉 复杂查询处理：大促期间电商涉及的查询操作较多，当客服进行发货、统计赠品等操作时，需要进行复杂的聚合查询处理，MySQL 面对这类 AP 类的查询时，响应时间显著增高。

订单中心系统上线 OceanBase 后，迎来了 2024 年的“双 11”大考。虽然过程中遇到了一些问题，但通过相关优化全都得以解决，最终比较圆满地支撑了这次“双 11”场景。为了避免大促期间的性能波动，保障业务的稳定运行，我们在前期进行了如下操作：

🔎 进行全链路压测，提前对系统进行压测，暴露风险点。🔎 对整体资源进行预估，根据需要对租户进行扩容操作。

🔎 使用 obdiag 工具对集群进行整理巡检，以发现可能存在的隐患。

🔎 提前发起合并，避免促销时数据修改过多引发性能问题，并且调整每日自动合并的时间。

尽管做好了迎接大促的准备，但面对新的数据库，在大促过程中还是遇到了一些问题。在 OceanBase 社区技术人员的帮助下，问题得以解决。问题 1：热点行，导致执行计划的多样性。

经过分析出现的 SQL，我们发现一个共同特点，即条件字段中使用 sku_no 字段，而 sku_no 字段存在严重的数据倾斜问题。在电商业务中，sku_no 代表商品的编号，商品存在热门款和普通款，当 SQL 传的参数是热门款时，由于需要扫描的行数较多，会选择其它条件字段的索引扫描作为驱动，而由于 OceanBase 的执行计划缓存机制， sku_no 的传值是普通款时也复用了该计划，而值少的正确参数应该使用该字段索引作为驱动，由于没有走到最优的执行计划，从而导致了 SQL 相应时间的整体提高。

解决办法是通过 Outline 绑定一个执行计划，实践发现，对于这部分 SQL，使用 sku_no 的索引作为驱动 SQL 的整体表现较好，即使传参为值较多的 sku_no 损失的性能也较为有限。因此，我们对这一部分的 SQL 进行 Outline 固定执行计划的处理。

问题 2：后台定时任务时间设置不合理，导致高峰期间前后台资源争抢。

OceanBase 缓存失效有以下几种原因：

💡 执行计划缓存使用的内存达到阈值，开始触发执行计划缓存淘汰。💡 SQL 中涉及表的 Schema 变更时（比如添加索引、删除或增加列等），该 SQL 在计划缓存中所对应的执行计划将被刷新。

💡 SQL 中涉及重新收集表的统计信息时，该 SQL 在计划缓存中所对应的执行计划会被刷新。

根据 22:00 点这个关键信息分析，OceanBase 收集统计的窗口恰恰是工作日的 22:00 开始，因此可以判断出是因为统计信息的收集导致 Plan Cache 的失效，大量 SQL 重新硬解析，而 SQL 的执行计划往往取决于第一次硬解析时候所传的参数值。如果硬解析时候传参对应的执行计划不是全局最优的，就可能导致该问题。

MONDAY_WINDOW  22:00/per week  4 hoursTUESDAY_WINDOW  22:00/per week  4 hoursWEDNESDAY_WINDOW  22:00/per week  4 hoursTHURSDAY_WINDOW  22:00/per week  4 hoursFRIDAY_WINDOW  22:00/per week  4 hoursSATURDAY_WINDOW  6:00/per week  20 hoursSUNDAY_WINDOW  6:00/per week  20 hours

对应的解决办法也比较简单，我们在大促前不仅要调整每日自动合并的时间，还需要调整维护窗口的时间，以避开大促业务时间。

问题 3：下游的同步业务增加了资源消耗，导致高峰期间资源争抢。

由于业务逻辑要求，新系统写入的每一条数据都要通过特定逻辑组装后同步到旧系统，因此 OceanBase 中的每一次数据变更下游系统都需要一次或多次的查询负载。增大的数据库压力在大促业务高峰时体现得尤为明显。大促使用的 OceanBase 版本备库不支持作为 OMS 源端(新版已经支持)，我们对架构进行了一定的优化。