0x01 游戏和直播间会碰撞出什么样的火花

游戏直播是玩家通过互联网平台实时分享其游戏过程和技巧的一种媒介。玩家可以通过这种媒介，与观众分享其游戏过程、探讨游戏玩法并可以展开小范围的实施讨论；观众则可以通过游戏直播内容“云玩游戏”，也可以学习主播的精彩操作，拥有更饱满的游戏体验。

不仅如此，在当前B站的直播生态下，还有一系列的帮玩、陪玩活动，如玩竞技类、MOBA类游戏想要追求更高段位、积分；沙盒、派对类游戏则又有沟通交流和联机的诉求。

作为国内最大的游戏社区平台，B站也适时地在直播场景推出了自己的游戏工具，允许观众线上和主播一起参与游戏互动的“一起玩”。我们将这部分的用户诉求进行了分析和整理，使原先野生的生态更“工厂化”、“系统化”，一方面提升了用户的使用体验，另一方面对主播和用户均做到了较好的保障。

图1 游戏在直播间的一种表现形式

0x02 技术如何支撑起线上一起玩游戏的能力

作为直播间的观众，用户是天然更有兴趣参与到主播的游戏或直播内容来，以达到增进与主播联系的目的的。基于此，我们设计了一套“一起玩游戏”的工具用于满足主播和观众间在直播间内完成账号交换、排队等位等诉求。下图是技术视角的业务框架展示：

图2 一起玩业务框架

“一起玩”整个功能是围绕着“主播提出要求，满足条件的用户参与排队”的逻辑展开。在核心的服务层部分，我们完成了 主播配置要求和管理队伍、用户匹配主播，绑定账号和加入队伍以及运营操作干预的能力。

一、 主播的组队要求

考虑到实际的直播效果，我们给主播提供了丰富的粉丝要求门槛，避免过量的用户加入队伍超出主播服务负荷，降低主播服务质量和用户体验。

在落地的功能上，我们按照 粉丝勋章等级、大航海身份、是否是粉丝 等条件对主播的粉丝群体进行细化拆分，主播可自主选择对应的要求类型和要求等级进行配置，确认后用户需要满足对应的身份才可以加入到游戏组队中。

在具体的实现上，服务端在整个流程中串联了 关系链、大航海、粉丝勋章 等主播私域业务，将粉丝群体按照不同的亲密关系进行区分，方便主播对不同层次的粉丝群体进行针对性的陪玩服务，促进直播间观众和主播的良好交流氛围和亲密关系维系。

二、 用户参与主播游戏

主播在发布完组队要求后，用户可以点击“立即申请” 进入排队页面，如果队伍没有满员，即可进入主播的“等待队列”中。

图3 一起玩业务展示图

如上，满足条件的用户在主播直播间内加入到“等待队列”后，主播的开播工具端即可实时查看在“等待队列”中的用户。主播可以选择将用户从“等待队列”中移除，或者将其移动到“游戏队列”中。

这个核心操作过程我们采用了两个 redis 的 ZSET数据结构来维持。我们利用了 redis 的原子性确保了分布式系统下的数据不发生错乱，同时利用了 ZSET 的 “集合” 概念在业务上保证了单用户在队列中出现的唯一性，最后将 ZSET 独有的 score 值赋予时间戳含义解决了队列中用户排序的难题。相比于传统意义上的关系型数据库，Redis 因其原子操作和存储于内存的速度优势，在保证了整个队列系统的高可用性的同时，也大大提升了主播操作和用户查看的速度。

图4 控制核心逻辑的Redis 数据结构

由于Redis存储更多的是用在缓存场景，出现一些意外的情况可能会出现数据丢失的情况。同时，非结构化的数据也不利于后期对数据的统计。所以，我们在实际操作的时候，也会同时存储过程数据到 MySQL 中，一方面是确保每次操作都有记录，另一方面也可以避免出现问题数据无法复原的情况。

我们最终使用了一张事实表记录了用户行为流水，另一张状态表则用于记录用户在队伍中最新的实时状态。

图5 事实表记录用户行为流水，状态表用于记录用户实时状态

事实表最终会记录用户的每一次行为流水，我们在其中按照用户行为的类型分为不同的行为科目，如“进等待队列”、“出等待队列”、“进游戏队列”、“出游戏队列”等，这些事实流水的记录一来是可以方便还原用户的操作现场，提供有力的问题排查工具；二来相当于是 redis 操作的“binlog”，能帮助还原异常导致的有错误的结果。

状态表主要记录了用户的一次“组队行为”的完整生命周期，表内会记录用户加入、离开队伍的时间、原因等，同时通过字段赋值内容也可以轻松的判断出当前“组队行为”流转到哪一步以及是否完结。这张状态表一方面可以快速判断用户“组队行为”的状态，另一方面可以做一些数据分析的工作，如分析哪些主播比较受欢迎、用户平均出队的时长、主要原因等。

三、 更多推荐主播数据构建及展示

对于用户而言，平台提供的可组队主播如同大海繁星，在众多主播中找到合适且有空位的主播可谓难如大海捞针。基于此，我们也设计了一套实时的主播推荐系统用于内容推荐，方便更好地促进游戏组队。我们在其中应用了大数据能力、定时脚本构建分钟级数据等能力，确保用户能在分钟级筛选到合适且有空位的主播一起玩游戏。

图6 分钟级更新的可供用户筛选的准实时主播推荐列表

如上图所示，我们会先从数据仓库中按照 主播T+1 ACU 数据对主播进行分层，经过是否开播、是否有开启功能进行过滤，将这些在线的游戏主播按照 不同ACU分层、不同开播分区进行推荐列表构造，按照缺人数进行倒序排序，引导用户加入“更缺人”的队伍，方便促进更多的直播间的组队游戏活动。

不仅如此，我们还会优先给用户推荐“组队过”的主播。希冀能建立强关联，方便组队的同时也希望用户可以在直播间内和主播有更多、更密切的互动。

0x03 B站对游戏主播提供虚拟服务支持的实践

对于竞技类或者有天梯排位玩法的游戏，更强实力的主播往往会更受亲睐。观众在直播中一方面能看到“大神玩家”的精彩操作，另一方面也希望“大神玩家”可以带自己上分或者由“大神玩家”亲自操作自己的账号帮助自己达到理想的段位或者分数。由此，“帮我玩”或者“游戏代练”的诉求应运而生。由于直播间天然的沟通土壤，更容易促成“大神主播”和消费群体之间的沟通交流，进而促成直播场景下的消费和表演，最终达到主播获取收益、用户达到段位、直播间丰富内容的多赢局面。

在技术实现方面，我们将业务划分三个核心模块——主播编辑维护的商品系统（goods）、用户消费服务的订单系统（order）以及用户消费主播结算所依赖的船票（ticket），具体技术框架如下图所示：

图7 帮我玩业务架构

整个系统中，用户的购买行为被抽象为“消耗ticket购买goods创造order”的过程，生成的订单再经过后续一些状态机流转（如取消、发货、确认订单等）管理订单生命周期，最终完成一次主播和玩家的撮合。

除了上述的核心系统，我们也有一些依赖的周边系统如大航海或者直播间礼物的船票兑换逻辑、船票数值增删改查所依赖的高可用数值系统的对接与对账、安全管控系统等。这些系统作为“帮我玩”业务的基石，是其安全稳定运行不可或缺的一部分。

一、 如何管理主播提供的虚拟服务

主播作为“大神玩家”，是需要自定义编辑、保存、上架自己的商品的，而且按照不同的要求、不同的段位，所要求的售价也不尽相同。我们在调查、走访了大量主播和直播间后，将主播的商品进行了工厂化的抽象，分为 标题、游戏名、区服、售价、详情 等五大模块，同时针对有个性化定制要求的用户，也开辟了“私单商品”的概念，允许主播只针对单个观众发起限时的商品邀请。

相比于之前直播间贴片广告的形式，结构化的信息内容可以让用户更快地筛选到自己想要的服务，同时也美化了直播间装修，让用户可以沉浸在直播表演内容而非广告上。

当然了，直播场景中，主播对外提供内容的安全工作也不容忽视。技术侧提供了关键词打分过滤、人工审核上架、线上商品巡查的三位一体安全防护措施，确保了线上主播提供服务内容的安全性和合规性。

二、主播和用户如何通过一笔订单

串起服务的流程？

用户在浏览到主播的商品后，可以通过在直播间内消费大航海或者专属礼物获得的“船票”来进行消费。用户在支付的那一刻，后台就会生成一个order_id用于记录这笔订单的生命周期。整个订单的生命周期中，可能有很多分支最终走向订单取消和订单完成两个终态。对于中间状态，我们设计了一套简单的状态机进行状态管理，如下图所示：

图8 帮我玩状态机示意图

用户或主播在进行任何一项操作之后，都会进入一个唯一的状态，我们设计了两台状态码分别用于对内存储和对外展示。每个内部状态码都是这个状态机内部的一个个原子状态，它背后对应了一个外部状态、用户展示、主播展示以及一些预期上一个状态。

实际代码中，用户在每次操作的时候，都会调用网关不同的接口，之后会通过一个统一的 handleOrderStatus 方法来收口控制订单的状态流转。这个方法会先做一些权限、订单归属的判断，之后再通过判断先前状态是否与 ExceptedFrom 匹配来保证流程按照预期执行，避免出现“订单取消被接单”、“订单被重复完成”的异常情况，最后再将状态数据更新到数据库中，并发送相关消息和通知到下游系统，如弹幕、通知卡等。

图9 帮我玩状态一览表

三、除了实现基础功能，业务研发还能

为业务带来什么价值？

技术侧对于业务的支持不应当仅仅体现在实现功能上面，在帮我玩能力上线后，我们不仅应用哔哩哔哩技术提供的日志、告警、业务埋点能力，对线上业务进行实时的监控和维护。这套监控告警系统可以让研发人员能分钟级发现线上异常情况或订单，并能及时介入处理，同时，基于上下文的tracing系统也能方便快速定位到问题所在。

图10 实时业务监控状态监控

帮我玩犹如一辆高速行驶的汽车，业务实时监控告警在航行中相当于车辆的各项监控指标，保证车辆能安全地前进。而如何走、往哪去则需要有地图、导航的参与，这在我们的系统中就是离线数据处理和分析的部分。技术侧针对业务模型中核心的三大模块分别做了针对性的离线数据处理及分析，从“商品”、“船票”、“订单”三个维度出发，下钻到游戏类型、主播分类、用户画像等，方便产运早发现问题早修正业务方向，促进业务团体的共同成功。

图11 离线数据分析与报告对业务的领航作用

当然了，除了导航和仪表监控，我们也需要一套“驾驶系统”来实质性地推进业务前进。这套“驾驶系统”在车辆上相当于方向盘和油门刹车，而在帮我玩业务上就具象为一个个的“运营工具”。研发侧开创性地将UAT环境的造数、测试工具进行一些合规改造，变成了lego后台的一部分，可以由产运同学申请权限并对基础的“商品”、“订单”和“船票”模块进行查看以及操作。一方面项目成员可以更实时地感受到线上业务，更真实地观察到每一笔订单的生命周期；另一方面，拥有管理权限的项目成员也可以对这些商品或订单进行人工干预操作，维护社区稳定。

0x04 关于游戏直播互动，

技术还能做哪些支持？

如上所述，“一起玩”和“帮我玩”功能是目前B站对游戏直播互动生态的主要探索内容和业务尝试。当然，由于产品需求优先级、厂商合作等客观因素也未能将它们做的尽善尽美。

如“一起玩”仅做到用户可以在B站登录游戏账号，方便双方复制游戏ID添加游戏好友；但更成熟、系统的对接如“展示游戏队伍”、“显示主播或用户段位”、“观众一键进入队伍”等基础能力均没有做到自动化，确实有一定的遗憾。

“帮我玩”部分排名次序完全依赖离线数据计算，这部分也不如接入AI算法推荐更准确、或者实现“用户提出诉求平台匹配主播”能更方便更能促进帮玩订单的产生。

相信上述问题在后续迭代版本中都能得到妥善的解决，技术也能为直播、游戏双修的玩家带来更多的价值与便利。

-End-

作者丨哎哟弟弟