如何通过OceanBase的多级弹性扩缩容能力应对业务洪峰
每周四晚上的10点，都有近百万的年轻用户进入泡泡玛特的抽盒机小程序，共同参与到抢抽盲盒新品的活动中。瞬间的并发流量激增对抽盒机小程序的系统构成了巨大的挑战，同时也对其数据库的扩容能力也提出了更高的要求。
但泡泡玛特的工程师们一点都不慌。因为基于 OceanBase 云数据库 的泡泡玛特新一代分布式抽盒机系统已经正式上线，数据库扩容和缩容时间降低 90%，在新品发售等高并发场景的系统连续性达到 99.999%，让在线“摇一摇”的抽盒体验更加流畅。这也是潮玩界，首例采用国内完全自主研发的分布式数据库，完成核心系统升级。
这个抽盒机小程序的系统稳定有多重要？据 2022 年年度财报，泡泡玛特中国内地收入约 41.6 亿元，抽盒机小程序贡献了约 9.5 亿元，接近四分之一。2018 年 9 月 2 日，泡泡玛特推出抽盒机小程序，将现实的抽盒乐趣搬到线上，同时依靠多种玩法，收获大量粉丝，至今会员数量已增长至 2600 多万，活动高峰期的瞬时并发量极大地挑战了泡泡玛特的数据库扩容和缩容能力。
为了更灵活、低成本地实现数据库扩容和缩容，既能满足业务低峰时期的较小需求，减少浪费，也能在业务高峰时期快速扩容，保障新品发售稳定，经过严苛选型测试，泡泡玛特选择已连续 10余 年稳定支撑“双11”的 OceanBase，搭载其云数据库 OB Cloud，打造了新一代分布式抽盒机系统。
1. “抽盒”流量高峰场景的挑战
泡泡玛特主要销售潮流玩具，推陈出新速度快，基本每周都会发售新产品。每当新品发售时，近百万名消费者会在同一时间涌入抽盒机小程序，这种类似电商“秒杀”的场景往往会带来流量突增，系统需要处理的数据量也越来越大，以往的传统集中式数据库扩容和缩容能力有限，这就容易造成线上抽盲盒时卡顿或延迟，影响用户体验。
所以对泡泡玛特而言，流量的剧烈波动属于常态，要更好地应对流量急速变化，泡泡玛特业务数据库扩容和缩容能力也需要进行灵活调整：
- 在业务低峰时期，以较小规格稳定运行，减少浪费；
- 在业务高峰时期，快速进行数据库扩容，保障新产品发售的稳定。
而 MySQL 等传统单机数据库扩容和缩容能力有限，MySQL 的主备架构扩缩容只能通过更换服务器规格来实现。具体而言，MySQL 的扩缩容需要先挂载一台更大规格的服务器，作为一个备节点从主节点同步数据；待数据同步基本完成后，再进行一次主备切换，才能完成升配过程。
整个 MySQL 数据库扩容和缩容的过程一定会涉及服务器层面的物理调整，必然带来较大的额外开销。由于 MySQL 的主备切换会带来一定时间的业务闪断，为不影响用户体验，泡泡玛特的运维团队在进行 MySQL 的主备切换时，通常都会在业务低峰期如凌晨进行操作。
在之前很长一段时间，泡泡玛特运维团队都要提前评估新品发售流量，按照最极端的场景预估数据库所需的规格，然后在发售日前一天凌晨业务低峰期进行数据库扩容。在发售结束后，也要进行同样流程的缩配操作。这就衍生出两个问题：、
- 容量预估异常困难。为了保证每周新品发售的全过程安全，往往要按照最大可能的流量来进行数据库扩容，通常会带来比较大的浪费。
- 运维人员压力过大。为了最大程度地降低对业务的影响，通常都需要挑在凌晨的时间进行升降配。
此外，泡泡玛特有多个不同业务，需要部署大量的数据库实例，导致数据库实例较多，管理复杂度高。这给数据库成本控制、有效运维，以及关键业务的流量波动都带来了挑战。那么，如何更灵活、更安全、更低成本地实现灵活的数据库扩容和缩容，完美支持每次新品发售的流量洪峰，让每一位潮玩爱好者都能够享受更丝滑的抽盒体验，成为泡泡玛特最关心的问题。经过严苛选型测试，泡泡玛特最终选择携手已连续 10 年稳定支撑“双 11”的 OceanBase，搭载 OB Cloud 打造新一代分布式抽盒机系统。
2. 多极弹性伸缩，轻松应对“抽盒”潮流
多级弹性伸缩，是让泡泡玛特抽盒机能轻松应对抽盒流量高峰的秘诀。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 升配进行数据库扩容的整个过程对应用基本透明无感知。
第三级弹性伸缩：机器数量的调整（即水平扩缩容）
这是 MySQL 主备架构做不到的一点，因为 OceanBase 是原生的分布式数据库，支持分布式事务，所以可以做到无感知的横向数据库扩容。更直观的说，就是 OceanBase 集群增加机器，业务流量就会自动迁移到新增的机器中。并且在这个过程中，应用是没有感知的，可以像使用一个单机 MySQL 那样继续使用这个有多台机器的集群。
这一点在很多工程实践中，被证实了是分库分表方案的更优解。同样，经过泡泡玛特的实践，考虑到可能出现超级爆款的新产品，增加机器数量的数据库扩容方案，给泡泡玛特面对超大流量提供了经得住考验的解决方案。
目前，泡泡玛特的核心抽盒机系统已经搭载 OB Cloud 全新出发，通过 OceanBase 的租户级弹性降低了 90% 的数据库扩容和缩容时间，集群级弹性可轻松应对秒杀期间的百倍流量，新品发售等高并发场景的系统连续性达到 99.999%，让在线“摇一摇”的抽盒体验更加流畅。
泡泡玛特和 OceanBase 都创立于 2010 年，分别在文创和科技领域深耕 13 年。如今，泡泡玛特核心抽盒机系统已登录 OB Cloud，未来还将推动供应链、IP 商品运营等系统逐步上线。国潮文创与国产科技共舞，让泡泡玛特的每一笔「抽盒」都算数。OceanBase 是蚂蚁旗下的自研原生分布式数据库，已应用于超过 1/4 国内头部金融机构。OB Cloud 是 OceanBase 的云数据库产品，支持企业在 AWS、阿里云、腾讯云等全球主流公有云上部署，让全球不同规模的企业在云上以更便捷的方式、更低的成本使用分布式数据库，满足高性价比的数据库扩容和缩容需求。
OceanBase 云数据库现已支持免费试用，现在申请，体验分布式数据库带来全新体验吧 ~