十几万人同时在线的直播间聊天如何设计服务端架构?

GitLife 发布于 2016/04/07 12:59
阅读 8K+
收藏 4

MySQL连接为什么挂死了?别踩坑!>>>

如题,这是在知乎上看到如何搭建视频直播系统时想到的一个问题,在此不考虑其他直播上的问题,仅考虑聊天系统,一个热门视频直播间人数可能达到几十万人,一个人发消息几十万人接收,几十万人发消息几十万人接收,这个流量相当惊人,服务端要如何设计才能保证系统流畅?

希望大家给出自己的思路,谢谢。

加载中
1
公孙二狗
公孙二狗

可以用多级处理的方式,1 台服务器带 100 台 2 级服务器,一台 2 级服务器带 5000 个客户端,同一条消息服务器间转发也就几百次,每个服务器再转发给客户端,关键是要做好路由,Failover 等

想用一台服务器带几十万个客户端不太现实

IdleMan
IdleMan
这个貌似有点道理。主服务器只负责接收post和散发消息给周边服务器,周边服务器负责把消息发给客户端
0
x
xyz20003

直播服务器和消息服务器是分开的。

视频方面一路上行,多路下行,可以用cdn做内容分发。

消息服务器用来做即时消息转发。

m
mikeduan
回复 @xyz20003 :
x
xyz20003
回复 @GitLife : 只是im的话,看过融联云的文章,说他们一台机器就可以支撑几十万用户。考虑自己的优化没那么高级,需要几台机器集群也并不难。因为im本身的消息比较小。难点其实还在视频这种消耗带宽的大家伙上。
GitLife
GitLife
汗。。题目已经强调了仅考虑聊天,不考虑其他,不是讨论视频直播的,不过谢谢哈
a
akzhao
直播应该是用不了CDN的吧
明月惊鹊
明月惊鹊
直播也用cdn的
下一页
0
YanXI
YanXI

不会让那么多人一起交流的 分个区 xxx人一个房间 

爱吃荷包蛋i
爱吃荷包蛋i
回复 @GitLife : 那是每个分区都显示总数了而已。实际还是分开的
GitLife
GitLife
有的啊,你去看那些热门的英雄联盟直播,上几十万人看很正常,都能在一个房间聊天的
0
老陌
老陌

从一个用户的角度来考虑:几十万人的聊天室,我能把消息逐一看完吗?肯定不能!那么,就没有必要实时推送了,所以,简单的用留言板模式改改就OK。

另外,直播系统都不是实时直播,都有延迟,所以是能用CDN分发的。

0
爱coding
爱coding
1台主服务器,N台消息分发代理服务器,主服务器做好扩展,一旦代理服务器并发连接数高的话,消息会丢失,就立即考虑加入代理服务器,各个客户端,就近选择(用cdn方式灵活选择)代理服务器登陆。我们的聊天服务大概就是这么个架构,java通讯框架用的是netty4。
0
游侠
游侠

几十万聊天还好,不过有一点优化就是一个直播间可能是几十万人,但是分成了几十个甚至是几百个个房间,也就是说一个聊天室可能是几千上万人而已。你想想,如果是几十万人甚至上百万人都在一个房间聊天,那聊天内容肯定是刷得太快没法阅读的。

IdleMan
IdleMan
直播弹幕 不全屏确实看不过来
0
网易云信
网易云信

一、聊天室架构应该满足哪些条件

1. 高可用:任何一个节点故障都不应该引起服务不可用;

2. 易扩展:具有水平扩展的特性,对不同量级的在线用户数都有应变的能力;

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

4. 客户端兼容性:新型的应用都是能同时跨多种设备实现消息互通的,比如网页端,手机端和桌面端,甚至智能电视等;

二、设计架构

客户端层:处理各种设备的兼容问题,包括对iosAndroidWindowsWeb等各种开发平台的语言适配;消息通道的管理维护,包括移动设备上的弱网络管理,断线重连等;保证数据安全,所有上行下行的数据包都需要加解密处理,规避数据泄露或中间人攻击等各种安全风险;

网关接入层:管理大量客户端连接,单个节点可以维护的客户端数量在数十万量级;处理不同类型客户端的协议兼容,由于客户端实现技术的多样性,导致客户端与网关之间底层的数据通信协议存在差异,需要由不同的接入网关做协议转换;处理数据安全逻辑;跨网络的高可用逻辑,网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢?);广播消息的高效下行分发,将收到的广播消息分发到所有连接在本节点上的客户端;

路由层:作为业务层接入的中转,同时承担负载均衡和高可用的作用,单个业务节点处理能力达到瓶颈时更方便的扩容,路由层使业务层扩容对前置网关层完全透明;当一个网络的业务集群出现网络故障时,可以切换到备用网络,保证服务可用性;

业务层:处理聊天室内的业务消息,一个集群内有众多节点,节点角色相互对等,任何一个节点的故障会使整个集群的处理能力下降,但不会引起服务的中断,因为其他节点可以继续接管业务数据包的处理;业务集群同样有多个网络环境的热备,以应对可能出现的区域性网络故障;

三、难点在哪里

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

2、数据安全的保证;当前的网络安全形势异常复杂,开发应用时如果不在通信安全上花心思,那你的用户就是在互联网上裸奔;开发者需要针对不同的平台,不同的通信技术实现可靠的安全方案,避免用户数据在传输过程中泄露,避免中间人攻击等安全风险;

3、跨机房网络级的高可用方案,当机房网络出现故障时把责任推给市政施工队或者网络抽风已经不流行了,用户需要的是故障无感知;

4、所有环节的单点故障排除,任何硬件和软件都存在故障的可能,我们无法避免应用罢工,那就需要随时准备替补上场;

5、能应对任何用户量级的需求,架构级做到水平扩展的能力,当用户量增长时随时可以通过堆服务器来解决,而不是将架构推到重来;

四、这么难?我做不出来

技术发展到现在已经不流行重复造轮子了,因为轮子的结构越来越复杂,功能性和非功能性的指标要求越来越高;而我们的用户却不会再等我们了。当我们还在画轮子的图纸的时候,竞争对手可能已经把车子都造好,在路上跑了。虽然我们不是非得自己造轮子,但是了解如何完成一个完美的轮子的制作过程和质量标准却是非常有必要的,这也是我前面和你介绍了这么多的原因。

就像近几年大数据技术非常流行,如果你对这个领域有所了解你就会发现几乎所有企业都在使用现有的平台,比如Hadoop;或者直接使用,或者在上面做二次改造,原因无非就是上面说的几点。现在你遇到的也是同样的问题,聊天室这种功能在最近两年又火了起来,主要还是视频直播业务的大规模扩张;所以能借用目前已有的平台或工具是最快捷的路径,应用需要关注的是怎么以最快的速度抓住用户。

所以,最后一句就是硬得不能再硬的广告了: 接入网易云信吧,我们把轮子造好了,而且造得还不错!

郑岐-网易云
郑岐-网易云
并且网易云信提供一对一的技术支持哦,感兴趣的同学qq2479775187聊聊吧
徐舟
徐舟
6666666
0
若谷
若谷
转变思路,用redis存储消息内容,直播聊天室不要想着做push,聊天室里的用户定时去服务器拉取数据(如果有新消息,马上接着拉),十几万人同时在线的聊天,一台服务器搞定
返回顶部
顶部