OB Cloud助力泡泡玛特打造新一代分布式抽盒机系统

作为中国潮玩行业的领先者，泡泡玛特凭借 MOLLY、DIMOO、SKULLPANDA 等爆款 IP，以及线上线下全渠道营销收获了千万年轻人的喜爱，会员数达到 2600 多万。2022 年，泡泡玛特实现 46.2 亿元营收，其中线上渠道营收占比 41.8%，而抽盒机小程序是线上营收的重要来源。

为了让全国的潮玩爱好者能够随时随地在线抽盒，2018 年 9 月 2 日，泡泡玛特抽盒机小程序诞生。这款小程序模拟线下消费者的抽盒场景，将现实的抽盒乐趣搬到线上，同时增加了多种多样的玩法，收获了大量粉丝。

泡泡玛特主要销售潮流玩具，推陈出新速度快，基本每周都会发售新产品。每当新品发售时，近百万名消费者会在同一时间涌入抽盒机小程序，这种类似电商“秒杀”的场景往往会带来流量突增，容易造成线上抽盲盒体验的卡顿或延迟。

所以对泡泡玛特而言，流量的剧烈波动属于常态，要更好地应对流量急速变化，泡泡玛特业务数据库的规模也需要进行灵活调整：

在业务低峰时期，以较小规格稳定运行，减少浪费；
在业务高峰时期，快速扩容，保障新产品发售的稳定。

而 MySQL 等传统单机数据库扩缩容能力有限，MySQL 的主备架构扩缩容只能通过更换服务器规格来实现。具体而言，MySQL 的扩缩容需要先挂载一台更大规格的服务器，作为一个备节点从主节点同步数据；待数据同步基本完成后，再进行一次主备切换，才能完成升配过程。

整个 MySQL 扩缩容的过程一定会涉及服务器层面的物理调整，必然带来较大的额外开销。由于 MySQL 的主备切换会带来一定时间的业务闪断，为不影响用户体验，泡泡玛特的运维团队在进行 MySQL 的主备切换时，通常都会在业务低峰期如凌晨进行操作。

在之前很长一段时间，泡泡玛特运维团队都要提前评估新品发售流量，按照最极端的场景预估数据库所需的规格，然后在发售日前一天凌晨业务低峰期进行扩容。在发售结束后，也要进行同样流程的缩配操作。这就衍生出两个问题：

容量预估异常困难。为了保证每周新品发售的全过程安全，往往要按照最大可能的流量来扩容，通常会带来比较大的浪费。
运维人员压力过大。为了最大程度地降低对业务的影响，通常都需要挑在凌晨的时间进行升降配。

此外，泡泡玛特有多个不同业务，需要部署大量的数据库实例，导致数据库实例较多，管理复杂度高。这给数据库成本控制、有效运维，以及关键业务的流量波动都带来了挑战。

那么，如何更灵活、更安全、更低成本地实现数据库灵活扩缩容，完美支持每次新品发售的流量洪峰，让每一位潮玩爱好者都能够享受更丝滑的抽盒体验，成为泡泡玛特最关心的问题。经过严苛选型测试，泡泡玛特最终选择携手已连续 10 年稳定支撑“双 11”的 OceanBase，搭载 OB Cloud 打造新一代分布式抽盒机系统。

多级弹性伸缩，是让泡泡玛特抽盒机能轻松应对抽盒流量高峰的秘诀。OceanBase 的弹性伸缩能力包括租户级弹性和集群级弹性，后者涵盖机器规格和机器数量两个维度。泡泡玛特运维团队通过这三个层次的灵活搭配策略，轻松且低成本的解决了应对流量洪峰的难题。

第一级弹性伸缩：租户规格的调整

OceanBase 作为分布式数据库，内部把多台机器统一规划为一个资源池，资源池中又可以进一步划分一个个隔离的资源组，每个资源组就形成了一个租户的概念。

租户的存在，带来多级弹性伸缩的第一级。因为租户是 OceanBase 内部资源的划分，对租户规格的调整不涉及物理层面的资源调整，完全由 OceanBase 内核完成。这就使得 OceanBase 租户规格的调整，可以秒级生效，整个过程对应用完全无感知。

泡泡玛特运维人员在数据库操作中，可以在任意时间（比如白天正常业务进行时），调整租户的 CPU 核数和内存大小，整个租户的极限 TPS 就可以得到平滑提升。

此外，泡泡玛特借助 OceanBase 提供的原生多租户能力，将原有的几十套数据库实例，整合为 3 套 OceanBase 集群，原有的一个实例，对应 OceanBase 集群中的一个租户。当然，也可以全部集中在 1 套，考虑到业务线运维的区分，最终选择兼顾综合成本和资源分配的 3 套集群方案。

通过多租户的改造，运维团队的压力显著减少。通过租户规格的调整，泡泡玛特大部分的小业务流量波峰，通过核心业务租户规格的扩大，即可随时随地无额外花费完成。

第二级弹性伸缩：机器规格的调整（即垂直扩缩容）

面对相对较大的业务流量，简单调整租户规格可能还无法满足业务需要，这时候就需要扩大机器规格。比如，把集群从 30C 的规格扩容至 62C，来应对如 MOLLY 这样的超级 IP 新产品发售的流量。

前文提到，MySQL 的扩容过程就是一个主备切换的过程，会对业务有闪断的影响。而 OceanBase 是通过 Paxos 协议进行节点间的数据同步，Paxos 协议核心点是自选举，一份数据的三个副本投票表决出谁来当选 Leader，以及该日志是否提交。

相比于 MySQL 主从复制，这带来了两点优势：

第一，OceanBase 的数据同步单位更小，带来更高的性能和灵活性。OceanBase 的 Paxos 组以分区为单位，相比于 MySQL 节点级日志同步，分区粒度更小，避免了 MySQL 为保证全局顺序带来的性能影响。并且 OceanBase 支持分布式事务的能力，还允许不同分区的 Leader 不在同一个节点上，比如上图中深蓝色的 Leader 节点就分布在三副本中，实现多点写入的能力，可以充分利用多机性能，并支持下面增加节点的扩展方式。

第二，OceanBase 的同步日志更轻量，代价更小。OceanBase 的 Paxos 协议同步的日志为 OceanBase 内部的物理日志 clog。而 MySQL 的流程是主生产逻辑日志 binlog，binlog 同步给备机后转化成 relay log，再执行的过程。OceanBase 的 clog 更轻量，更高效，配合Paxos分区级的同步粒度，OceanBase 不会有 MySQL 令人头疼的主备时延问题。

体现在扩缩容操作中，更换机器规格时，OceanBase 也需要先挂载一台机器同步数据，但切换时 OceanBase 只需要进行一次 Paxos 的有主选举，也就是 Leader 完成自己最后一个日志提交后，主动放弃 Leader 身份，然后主动投票给另一个节点，完成平滑切换。相比于需要闪断的 MySQL 主备切换，OceanBase 升配的整个过程对应用基本透明无感知。