直播多人聊天室怎么设置（无上限人数直播聊天室如何实现）

雷锋网按：本文作者周梁伟，现任网易云信IM即时通讯云服务器端开发负责人。2011年加入网易，先后担任网易后台技术中心与网易大数据平台资深开发工程师，目前负责即时通讯领域的产品开发。

一、直播聊天室的形式和应用场景

在一般人的理解中，直播聊天室应该就是直播画面旁配一个聊天窗口，众多观看者在里面发表自己的评论（如图1），随着移动互联网技术的发展和受众群体的转移，这种简单的聊天室已经满足不了广大网民的需求，参与者更加关注和主播之间的互动体验。

图1：直播聊天室形态

比如观众A平时就爱网红视频直播，进直播室就要点亮自己，发弹幕和主播对话，高兴的时候要送礼，还要和其他粉丝聊天。观众B热衷投资，对投资大师们的动向分析实时关注，现在大师们开直播了，不仅可以听取知识还可以实时互动，有问题及时解答。

我们发现在直播聊天室的互动形式已经非常多样化了，常见的像评论、点亮、弹幕、送礼等（如图2）。而适用直播聊天室的场景也越来越多，如网红直播、在线教育、在线游戏、在线金融等，直播的平台也从单纯的网页端向移动端、网页端和PC端等多平台转移。开发者通过直播 聊天室实现了真正的全民互动，使舞台已经不属于少数人，人人都能参与其中。

图2：直播聊天室新形态

二、稳定的无上限人数直播聊天室的标准

现实也不总是那么美好。以下这个画面（图3）是不是很熟悉，一打开直播画面就卡住，几万人同时嗨翻全场，弹幕堆满屏幕，女主播的脸卡成好几节，有的时候甚至都进不去直播间。这样的直播聊天室体验是不是太差了？

图3：弹幕卡顿

在讨论聊天室设计之前，我们先了解下几种常见的虚拟社群形态。下面的表格，我们从参与人数、消息送达即时性、离线消息关注度等维度对论坛、IM P2P、IM群和聊天室这几种常见的虚拟社群形态做了简单对比，从这个对比可以看到聊天室是一种不同于论坛和群模式的一种虚拟组织。

图4：常见虚拟社群形态的对比

聊天室跟普通的IM群（微信群，QQ群等）相比最大的不同点在于它是一个比较开放的虚拟组织。我们可以将直播聊天室比喻成一个广场，广场是开放无边界的，所有的人都可以随进随出，而群就像一个房间，是一个有边界有容量上限的私密组织，并且进入这个房间需要一定条件，一般是主动申请加入或被邀请加入。

聊天室对比论坛和IM群来说，它既具有了IM群消息即时送达的特性又有论坛参与人数无上限的特性。

就聊天室的实现来说，目前比较流行的做法是直接在群的架构上改造，但是只要是群就有人数和离线消息的存入上限，聊天室人数越多，消息分发的压力越大，客户端的用户体验也会变差。

跳出之前的思维，我们要实现一个聊天室服务，可能面临下面这些问题：

客户端多样

通信数据安全需要保障

网络抽风/单点故障

用户量上来了，架构撑不住

消息投递慢

由此，我们提出聊天室服务需要满足以下特性：

跨平台：新型的应用都是能同时跨多种设备实现消息互通的，需要同时服务于网页端，手机端和桌面端，甚至智能电视等。

数据加密：客户端与服务器端之间的通信数据要避免泄露的风险。

高可用：任何一个节点故障都不应该引起服务不可用。

易扩展：具有水平扩展的特性，对不同量级的在线用户数都有应变的能力。

高并发低延迟：能支持大量的用户同时收发消息，消息从发出到送达所有在线端的延时在毫秒级。

那么如何克服那些难点并且搭建一个符合上述条件的直播聊天室？

三、稳定的无上限人数直播聊天室，技术上如何做？

开篇阐述了直播各种应用场景以及全民互动的需求，对应的问题是：一个热门直播间的人数可能达到几十万人，个人发消息几十万人接收，几十万人发消息几十万人接收，这个流量相当惊人，服务端要如何设计才能保证系统流畅？无上限人数和系统顺畅不卡顿，这两个条件如何在直播时同时满足？

网易云信在做聊天室服务时，将整个系统分成了：客户端层、网关接入层、路由层和业务层，来进行分别处理。

图5：设计架构逻辑

图6：各分层的具体内容

1、SDK实现多平台覆盖，满足客户端多样性：

目前的应用都存在跨平台的需求：iOS、安卓、网页端，甚至IOT物联网设备，能连多少是多少，多多益善。但是不同开发平台之间的技术差异性极大，不是所有公司都有这么全的全栈程序猿的；如果团队开发的话单就客户端开发人员就不是几个人可以完成的。

我们曾遇到过一个创业团队，他们想自己实现TCP长连接的逻辑，iOS开发的同学没日没夜干了一个礼拜，终于把第一个RPC请求调通了，结果又在数据包压缩瘦身和加密的坑里爬了大半个月，好不容易发了个demo版出来，结果发现移动网络下各种掉线，最后又不断优化弱网环境下的自动重连机制，负责安卓的同学则在边上观摩了一个月之后彻底放弃了，因为他要用java重新把iOS同学的Objective-C代码再重新实现一遍，里面有多少坑，能不能爬出来谁也说不准。而网页开发同学就直接懵了，因为他根本没法理解Web上的长连接是什么鬼，调研半天发现只能用websocket这种方案，但是这种方案已有的服务器又根本没法支持。

所以当你想去搭建一个无上限人数直播聊天室之前，先想想怎么解决这个客户端互通的问题。

所以当你想去搭建一个无上限人数直播聊天室时需要先想想怎么解决跨平台问题。我们的聊天室服务SDK需实现多平台覆盖，对iOS、Android、Windows和Web等开发平台都要提供原生SDK版本，最大程度上解决开发者跨平台需求的难题，使开发者能使用自己熟悉的开发语言和平台快速实现产品功能。

想象一下，我们生活中在手机（iOS、Android）、平板、电脑、可穿戴设备上都能实现看直播时自由聊天以及互动，那是一件多么美好的事情。

图7：多平台互通

SDK层还有一个重要的工作时是需要针对iOS和Android这种移动网络做弱网络优化。弱网优化有四个方式：

通过提前唤醒来降低重连过程中的网络状态切换、DNS解析等带来的延时开销，特别是针对Android等系统，我们通过维护后台长连接来使手机与服务器保存连接活跃状态；

通过数据包压缩来降低带宽的占用，提升请求在网络层的传输速度；

通过提供边缘节点使移动客户端总是能连接到距离最近的最优节点；

通过使用CDN等来提升多媒体资源的上传下载速度，开发者无需关心移动网络切换时网络断线重连等问题，提高连接的稳定性。

现在移动直播越来越火，各类户外直播也逐渐兴起，经常会处在弱网环境中，有了弱网优化的加持，我们在看直播的时候，也会更加顺畅，无需担心看到关键时刻而黑屏的情况发生，同时，还能与其他粉丝一起互动聊天。

2、客户端与服务器端的通信数据加密保证用户数据安全

当前的网络安全形势异常复杂，开发应用时如果不在通信安全上花心思，那你的用户就等于在互联网上裸奔。开发者需要针对不同的平台，对不同的通信技术实现可靠的安全方案，避免用户数据在传输过程中泄露。在选择一个云提供商时，他们应该具备哪些云安全认证和标准？是否有匹配具体安全服务类型的认证？其实安全需求跨度非常广，涵盖行业甚至企业自己内部，但是确有一些共性的需求来保证云安全认证和标准的开发。一些标准很明显是适用的，比如C-STAR认证和ISO27001，都是国际通行的信息安全方面的认证体系。

因此在通信安全方面，对客户端与服务器端之间的通信数据需进行加密处理，加密秘钥的有效期控制在单次会话粒度，每次会话需要通过非对称加密算法来协商本次会话使用的加密秘钥，再使用此秘钥对请求和响应包数据做流加密，加密之后的数据再对大请求包做压缩。 通过这种方式一则帮用户节省了网络流量，提高数据传输效率，二则保证了通信数据的安全性，规避数据泄露或中间人攻击等各种安全风险。

安全问题是最最重要的，谁也不希望在看直播、聊天娱乐的时候被第三方抓取到账号或聊天数据等隐私信息，所以加密处理是直播聊天室必须要做的，也是为了我们能享受这个网络虚拟环境在技术上做的努力。

图8：数据加密

3、架构的扩展性能应对任何用户量级的需求

聊天室服务应该具备水平扩展的能力，当用户量增长时随时可以通过增加服务器来扩容，而不需要将架构推倒重来。

Peter刚进入团队时跟我们分享了一个自己的故事，他和几个小伙伴之前做了一个分享周边美食的App，但是人手紧张啊，想着快速出成效，服务器简单搞了几个Tomcat，前端弄了Nginx就当高可用了，服务器和客户端的数据通讯就用简单的http协议实现了，开发速度是真快。iOS和安卓只要在客户端搞个http的库就把数据通信的事情搞完了，为了在一个分享内容发出去之后马上能被其他人看到，客户端同学天真地来了一个5秒轮询的逻辑，应用一进入前台就会定期拉取新内容，产品愉快地被推广出去之后，用户量几百人几千人时大家都一副很轻松的样子，但当用户量过万的时候就发现服务器撑不住了，5秒轮询的坑开始发威了。再然后就是竞品出来了，用户体验被完爆，这真是个悲伤的故事。Peter泪流满面：“架构扩展性真的好重要！”

所以无上限人数聊天室服务需要具备足够的弹性，在用户量级上来之后能支持快速的扩容，不会因为架构的问题需要重构。

网关接入层主要用于客户端长连接的管理，单个节点可以维护的长连接在十万量级。网关接入层还有一个重要功能是处理不同SDK的协议兼容问题，针对移动端和PC端等支持TCP长连接的SDK中我们实现了私有通讯协议，针对Web SDK则提供基于Socket IO的自定义协议，通过在接入服务器网关上对该协议进行双向解析转换来保证不同的SDK请求响应包格式统一；另外，网关接入层还要处理数据安全逻辑和跨网络的高可用逻辑，为此我们提供处于不同网络环境的多个可用域，当单个可用域出现网络故障时可以自动切换到备用域来保证服务不受影响；网关接入层还要实现海量聊天室广播消息的高效下发。

4、备用网络以防单点故障

任何硬件和软件都存在故障的可能，我们无法避免应用罢工，那就需要随时准备替补上场。

你一定听说过“蓝翔毕业生挖断机房光缆”这样的故事，也听说过天津港爆炸引起IDC机房受损这样的真实事件，当这种不可预测的天灾人祸降临的时候，如果能不影响服务的话那就更厉害了。所以现在各种云服务提供商都在提“异地双活”之类的高可用方案。

更不用提服务器宕机之类的这种家常便饭的小故障了，所以在服务设计时都需要消除可能存在的单点。

路由层承担了网关接入层和业务层之间解耦的功能，数据包到达接入层之后通过路由层中转送达到正确的业务节点。同时具有负载均衡和高可用的能力，在单个业务节点处理能力达到瓶颈时能方便快速的扩容；路由层使业务层扩容对前置网关层完全透明，当一个网络的业务集群出现网络故障时，可以切换到备用网络，保证服务可用性。

5、业务节点的可替代性

从业务层上来说，聊天室功能上的业务节点主要用于处理收发聊天室消息，成员进出鉴权等具体的业务逻辑，集群内有众多节点，它们角色相互对等，单节点的故障可能会使集群的业务处理能力受影响但不会引起服务的中断，在节点故障发生时可以快速增加新的替代节点（就是新开服务器）来恢复集群的业务处理能力，此外业务集群有多个网络环境的热备（这个就是上面说的多个可用域），来应对可能出现的区域性网络故障。

总之，以上的技术都是在为一个稳定而安全的直播聊天室服务，没有以上技术的加持，这一场主播和观众的互动聊天大戏是没有办法进行下去的，更别说全民参与直播、观看直播了。

三、总结

技术的发展让用户体验越来越出色，任何现实中的难点正在一个一个被攻破，技术人员的责任也是越来越重大。在直播应用如火如荼的今天，各种应用都在面临观众人数的急剧膨胀，产品需求的不断增加，流量高峰期不期而遇等问题。直播聊天室服务的稳定和高效对提升应用整体的体验至关重要。

本文为雷锋网独家约稿，转载请联系授权，不得删改文章内容。

,