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

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

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

前文中，咱们介绍了语音服务器分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台机器。

 

这样优势很是明显，转发服务器跟原有系统彻底解耦，原系统改造也很小，能够实现高可用。惟一缺点是转发服务器起码有两台机器，也会增长接收方数据去重的复杂度。

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

 

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

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

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