多点DMALL与OceanBase：实现租户间资源完全隔离与低成本系统升级

本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，点击链接获取完整版内容。
作者：杨家鑫，多点数据库团队DBA
在当今数字化转型的大潮中，企业面临着诸多挑战，尤其是在零售SaaS场景下，数据处理的复杂性和成本问题尤为突出。作为零售数字化领域的先锋，我们不仅是国内顶尖的全局数字化解决方案提供商，更在亚洲市场上占据领先地位。我们拥有上百个全渠道系统，涵盖会员管理、商品、营销、O2O、POS系统、WMS物流、AI出清、AI导购等多个关键环节，为零售企业提供全方位的数字化支持。我们的客户遍布国内、东南亚及欧洲等地，其中包括知名网红商家、全国性头部连锁便利店、合资连锁商超等。在业务高速增长的背后，我们也面临着来自零售SaaS场景和业务系统瓶颈的挑战。
本文将结合多点DMALL面临的挑战、OceanBase数据库的优势与选择、多点DMALL应用OceanBase的实践、OceanBase在多租户架构下的资源隔离实践等内容，分享我们借助OceanBase升级数据库架构、简化技术栈，从而实现降本提效的实践经验。
一、多点DMALL面临的挑战

（一）系统复杂度高

多点 DMALL 采用了微服务架构，其全流程业务环节繁多，系统应用规模庞大。与之对应的是，数据库数量已然超过 500 个。此外，随着系统持续迭代升级，数据规模呈现出不断增长的态势，这使得运维管理的难度日益增大。就如同在一张庞大而复杂的网络中，每一个节点都承载着关键业务，牵一发而动全身，运维人员需要时刻保持警惕，以应对可能出现的各种问题。
（二）业务增长快，水平扩展需求增多

随着业务的蓬勃发展，我们积极制定了出海战略，旨在海外开拓新的业务版图。然而，基于地区数据安全法的严格要求，必须独立部署一整套全新的系统来承接海外业务流量。在初始部署阶段，由于难以精准预估后期业务规模以及数据增长速度，数据库资源在初始阶段的分配成为了一大难题。为了有效控制成本，常见的做法是先分配较少的部署资源。但很快，业务的快速增长带来了数据的迅猛增长，此时如何快速实现扩容，成为了摆在面前的一道棘手难题。这就好比在高速行驶的列车上，突然发现前方轨道需要紧急拓宽，而时间却十分紧迫。
（三）需要在同一个集群中服务大量商家

便利店和连锁商超的 SKU（最小存货单位）规模差异较大，从几千到几万不等。在这种情况下，很难为每个商家独立部署一套系统。因此，我们的SaaS系统需要支持上百个中小商家客户，所有商家产生的数据在底层共享数据库资源。这就如同在一个大仓库中，不同商家的货物需要合理存放和管理，既要保证各自的独立性，又要充分利用仓库的空间，实现资源的高效共享。
（四）资源成本高昂

零售作为与民生息息相关的行业，其业务系统必须保持全天候运行。无论是供应链的采购、销售、物流环节，还是电商业务，除白天正常作业外，夜间乃至凌晨也依然活跃。这导致大量数据源源不断地涌入数据库，使得资源成本如同一条不断上升的斜线，呈现出无限制增长的态势。多点 DMALL 主要使用六种开源数据库，在整个生产环境中，数据库实例已超过一万个，数据空间规模也接近 10PB 级别。如此庞大的数据量和复杂的数据库环境，无疑给资源成本控制带来了巨大挑战。
（五）运维成本居高不下

在使用多种数据库的过程中，我们遭遇了一系列棘手问题，包括技术复杂性带来的难题、高昂的运维成本、烦琐的管理成本、巨大的学习成本以及复杂的交付成本。一套私有化环境的交付涉及上百个系统，以及上百套数据库集群和数百个数据库实例。这就好比搭建一座宏伟的建筑，每一个部件都需要精心安装和调试，任何一个环节出现问题都可能影响整个系统的正常运行，因此运维成本始终居高不下。
二、OceanBase数据库的优势与选择

（一）分布式数据库的优势

为了应对上述挑战，我们开始了数据库选型。由于分布式数据库支持更大的容量规模，具备透明扩展的能力，提供金融级数据安全，并且可以提高开发效率以及降低运维成本，能够更好地支撑业务发展。因此，我们坚定地认为它是数据库未来的趋势，此次选型仅调研了分布式数据库产品。
（二）基于业务的选型考虑因素

首先，从扩展性角度考虑，我们面临诸多挑战。目前，多个 MySQL 单库的数据量已超过 4 TB，并且仍在快速增长。当我们将最大的 MySQL 库切换到分布式数据库后，数据量已增长至 29 TB。面对数据的快速增长及 MySQL 容量瓶颈，DBA （数据库管理员）深感忧虑：

• 一方面，我们不断敦促研发团队进行数据清理和归档，但效果往往不佳，因为他们的主要工作是业务需求迭代，难以兼顾数据清理。
  
• 另一方面，考虑继续扩展磁盘空间。在云环境下，扩展空间相对容易，云厂商提供的块存储单盘容量可达 32 TB 或更大。然而，数据持续增长，仅通过扩展磁盘空间只是将问题延后，无法从根本上解决问题，未来可能会面临更大的困境。
  
• 此外，我们还可以选择分库分表的方案，但这操作烦琐、风险较高，且需要耗时数月。因为该方案会损害 SQL 能力，代码改造不可避免。
  

因此，我们期望利用分布式数据库透明且可扩展的能力，平稳支撑业务的快速增长。
其次，从运维成本角度考虑，在保证系统稳定性的前提下，我们致力于降低运维复杂度。以 MySQL 为例，假设一个数据库（database）是一个“蛋”，一个 MySQL 实例是一个“篮子”，那么部署 1000 个数据库时，应该如何合理分配到多个 MySQL 实例中？哪些数据库应该放在同一个实例中？如果将两个对资源要求都很高的重要数据库放在同一个实例中，可能会导致资源抢占。另外，如支付类数据库，虽然数据量不大，但对业务要求极高，也不宜与其他数据库放在同一个实例中。由于业务差异、优先级不同、数据增长速度各异以及 QPS（每秒查询数） 要求不同，DBA 经常需要调整数据库分布。即便不考虑资源成本，仅运维挑战就已相当大。我们期望分布式数据库能够解决这一问题，帮助 DBA 自动调整数据库分布（见图1）。

图1 使用分布式数据库实现“自动挪蛋”示意图

最后，从高可用角度考虑，我们期望保证集群的高可用能力。在运维 MySQL 集群时，我们通常采用 MHA、Orchestrator 等工具实现高可用，但它们都是“外挂”形式，本质上无法解决网络分区导致的脑裂问题（见图2）。因为数据库和 MHA 组件是两个独立的软件，不在同一个进程内，缺乏一致性协同控制。相比之下，MySQL 的 Group Replication 这类高可用架构更为可靠，它与 OceanBase 或 TiDB 等分布式数据库一样，基于 Paxos 或 Raft 分布式一致性协议，可以实现 RPO=0（数据丢失为零），RTO