OB Cloud助力泡泡玛特打造新一代分布式抽盒机系统
并且 OceanBase 支持分布式事务的能力,还允许不同分区的 Leader 不在同一个节点上,比如上图中深蓝色的 Leader 节点就分布在三副本中,实现多点写入的能力,可以充分利用多机性能,并支持下面增加节点的扩展方式。目前,泡泡玛特的核心抽盒机系统已经搭载 OB Cloud 全新出发,通过 OceanBase 的租户级弹性降低了 90% 的扩缩容时间,集群级弹性可轻松应对秒杀期间的百倍流量
作为中国潮玩行业的领先者,泡泡玛特凭借 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 升配的整个过程对应用基本透明无感知。
第三级弹性伸缩:机器数量的调整(即水平扩缩容)
这是 MySQL 主备架构做不到的一点,因为 OceanBase 是原生的分布式数据库,支持分布式事务,所以可以做到无感知的横向扩展。
更直观的说,就是 OceanBase 集群增加机器,业务流量就会自动迁移到新增的机器中。并且在这个过程中,应用是没有感知的,可以像使用一个单机 MySQL 那样继续使用这个有多台机器的集群。
这一点在很多工程实践中,被证实了是分库分表方案的更优解。同样,经过泡泡玛特的实践,考虑到可能出现超级爆款的新产品,增加机器数量的扩容方案,给泡泡玛特面对超大流量提供了经得住考验的解决方案。
目前,泡泡玛特的核心抽盒机系统已经搭载 OB Cloud 全新出发,通过 OceanBase 的租户级弹性降低了 90% 的扩缩容时间,集群级弹性可轻松应对秒杀期间的百倍流量,新品发售等高并发场景的系统连续性达到 99.999%,让在线“摇一摇”的抽盒体验更加流畅。
泡泡玛特和 OceanBase 都创立于 2010 年,分别在文创和科技领域深耕 13 年。如今,泡泡玛特核心抽盒机系统已登录 OB Cloud,未来还将推动供应链、IP 商品运营等系统逐步上线。国潮文创与国产科技共舞,让泡泡玛特的每一笔「抽盒」都算数。
更多推荐
所有评论(0)