8月27日至30日是一年一度的《英雄联盟》周年庆典。 由于各种因素，本次活动不支持离线观看。 为此，英雄联盟联合打造了百万玩家同时在线的聊天系统——内场观看区，可以让百万玩家同时在线交流。 这样一个拥有数百万在线用户的聊天系统，过去需要一定的人力，并且至少需要一个月的时间来搭建。 然而，借助云开发，只需一名开发工程师即可在短短2-3周内完成从开发到上线的整个过程。 ！ 那么，这个聊天系统具体是如何设计和实现的呢？

首先我们需要介绍一下本次活动的主要场景需求：

1.百万并发在线聊天室

每个虚拟聊天室可容纳5人观看比赛，并支持实时互动，包括聊天、发送表情、动作等互动方式。 此外，聊天室还设有团队支持等模块。

2、房间搭配

玩家每次进入网页时，系统都会查询当前房间的匹配状态。

3、百万并发实时抽奖活动

观看直播的玩家可以在游戏中的某个时间点点击页面上的“宝箱”参与实时抽奖。

以上三种场景面临着不同的压力：

首先，在聊天室场景中，由于涉及到聊天信息的存储和分发，除了消息推送的实时性考验之外，最大的考验就是数据存储层的压力。 对于百万级直播场景来说，比赛的关键时刻往往是玩家最活跃、互动最频繁的时候。 100W的理论峰值QPS无疑会给后端存储带来巨大的压力。

接下来，房间与场景相匹配。 上面介绍了，进入页面后第一个逻辑是查询当前用户的历史房间ID。 这看起来压力不是很大，但考虑到极端情况，如果直播卡住，大量用户同时刷新页面，那就是个问题了。 系统的稳定性带来了巨大的考验。

最后，如何保证百万用户在实时抽奖中几乎同时完成“点击抽奖”的抽奖互动也是一个很大的挑战。

那么云开发如何一一克服这个聊天系统的三大挑战呢？

一、应对聊天室场景的数据压力：一个字——“拆”！ 聊天信息的数据流被分解为50个环境，系统分为主环境和聊天室环境。 主环境用于承载房间匹配、用户房间查询、房间数据库环境映射关系查询等通用逻辑后端； 聊天室环境负责虚拟房间内玩家的实时交互，包括文字消息、表情、动作等。

聊天室数据拆分的整体流程

解决了数据压力的问题后，聊天逻辑的实现就比较清晰了：根据监控室的聊天记录，当有人发送消息并写入聊天信息时，云开发的实时推送能力会自动推送聊天室中的所有听众和玩家都可以看到聊天消息。 至于表达式和动作之间的交互，底层也将它们转换成json对象来显示。

聊天记录数据结构示例

接下来，应对大量用户同时刷新页面的高并发风险的方法：一个关键词——“频率限制”。 具体来说，虽然云开发自带的云功能具有承受高并发的能力，但查询历史房间ID需要操作数据库。 为了保证数据库层不被压垮，最好利用云函数的限频能力。 来解决这个问题。 只要在前端尝试一下，优化UI交互，就能完美应对极端情况的风险，节省成本。

最后，关于百万用户同时开始抽奖的实时压力：还有一个关键词——“原生”。 云开发提供的实时数据推送能力可以完美支撑这一场景。 开发者只需要写一行代码就可以改变后端数据，无需进行其他操作（）。

此次《英雄联盟》九周年活动，云开发利用实时数据推送、弹性伸缩能力打造了百万级在线实时聊天系统，克服了数据存储压力、高并发风险、实时性要求高。 三大挑战是承受百万级流量高峰、支撑活动快速开展、降低时间和人力成本。