如何实现百万级的语音聊天室 - 好文

上篇我们介绍了如何从零开始搭建一套语音聊天室后台，设计方案比较基础，本篇我们将介绍语音聊天室的升级版本——在海量用户同时在线的情况下，语音服务器的架构将如何升级改造。

互联网产品后台开发信奉一句话：先扛住再优化。工程师当然是希望把系统设计得尽善尽美，但是业务发展往往是不允许的，因此后台工程师的工作就是在技术和业务之间寻找平衡点。大部分的系统都是逐步迭代演进而来的，没有一蹴而就的完美系统。

前文中，我们介绍了语音服务器分SET部署的概念。其实一直在回避一个问题，分SET的缺点是什么？

分SET限制了房间的容量。因为不分SET还好，分SET了以后一个房间撑死只能达到20万的用户，这样看起来分SET是一个不合理的设计。真是这样吗？

当然不是。所谓万丈高楼平地起，基础架构是非常重要的。虽然分SET为我们带来了一个限制，但是它的好处是更明显的。首先，我们的业务场景就决定了百万级别的房间是不常见，我们负责的超过20万用户在线的直播也就只有大型的游戏赛事直播，而且这种直播一年也就那么几回。其次，前面已经说过，如果不分SET，应对百万用户房间，需要50台机器，每次发布出错的影响面远大于分SET部署。

因此，我们要讨论的不是分不分SET的问题，而是怎么在分SET的情况下，实现百万房间的问题。

最容易想到的方案是把100万用户分到5个SET里。那多个SET之间怎样通信呢？方法说白了就是为不同SET中的服务器提供一个全局视图，用于转发路由。方法有很多种，这里介绍2种思路。

第一种是在房间服务器的上面再增加一个组服务器（group server），为系统提供全局视野。组服务器在每个SET的语音服务器中选取一台做为
桥头堡机器（broker）
，跨SET转发和接收都通过broker完成。Broker收到SET内转发时，会将数据转发给其他SET的broker；而当收到跨SET转发时，会将数据转发给SET内的其他机器。

这种方案的缺点是broker会成为瓶颈，当broker宕机时，最严重的情况是造成其他SET无法提供服务。容灾策略一种是减少broker到组服务器的心跳间隔，使组服务器可以迅速发现异常并重新挑选broker；另一种方法是采用双broker，不过会增加数据去重的复杂度。

第二种是在系统之外增加一个转发服务器
，专门负责跨SET转发，当然它本身拥有全局视野。这种方案其实是把上面说的组服务和双broker结合在一起，把转发功能外化。对于跨SET房间，主播所在的语音服务器做SET内转发的同时将数据发给转发服务器，转发服务器根据房间信息将数据转发给其他SET的任意1台机器。

这样优点非常明显，转发服务器跟原有系统完全解耦，原系统改造也很小，可以实现高可用。唯一缺点是转发服务器起码有两台机器，也会增加接收方数据去重的复杂度。

现在我们梳理一下，要实现一个支持百万级的语音聊天房间，整体的架构如下所示：

* 用户创建房间。通过目录服务器创建，实际上是在数据库中增加一条set_id和room_id的映射记录。
*
用户请求进入房间。通过目录服务器查询应该连到哪台语音服务器，具体的逻辑由负载均衡服务器实现。简单描述为：查询到room_id所在的set的所有语音服务器，根据负载情况和就近接入原则，选择几台语音服务器的ip和端口返回。
* 用户进入房间。客户端连接语音服务器，语音服务器将进房请求透传给房间服务器，房间服务器记录房间架构信息，并定期同步给set内所有的语音服务器。
* 对于小房间，通过set内转发语音实现。

对于跨set的大房间，由多个房间服务器协同工作实现。房间服务器之间不需要互相通信，它们只要在set内按规则挑选一台语音服务器作为broker。Broker收到语音数据时，除了常规的set内转发外，还将数据发给转发服务器。转发服务器知道房间所在的set列表和每个set的broker，从而实现跨set转发。

本篇主要介绍了基于分SET架构如何实现百万级房间的设计方法，并梳理了语音聊天室的整体架构。希望对大家有所帮助。

热门工具换一换