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


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

前文中,我们介绍了语音服务器分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架构如何实现百万级房间的设计方法,并梳理了语音聊天室的整体架构。希望对大家有所帮助。

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信