可以用多级处理的方式，1台服务器带100台2级服务器，一台2级服务器带5000个客户端，同一条消息服务器间转发也就几百次，每个服务器再转发给客户端，关键是要做好路由，Failover等
想用一台服务器带几十万个客户端不太现实
直播服务器和消息服务器是分开的。
视频方面一路上行，多路下行，可以用cdn做内容分发。
消息服务器用来做即时消息转发。
不会让那么多人一起交流的分个区xxx人一个房间
从一个用户的角度来考虑：几十万人的聊天室，我能把消息逐一看完吗？肯定不能！那么，就没有必要实时推送了，所以，简单的用留言板模式改改就OK。
另外，直播系统都不是实时直播，都有延迟，所以是能用CDN分发的。
几十万聊天还好，不过有一点优化就是一个直播间可能是几十万人，但是分成了几十个甚至是几百个个房间，也就是说一个聊天室可能是几千上万人而已。你想想，如果是几十万人甚至上百万人都在一个房间聊天，那聊天内容肯定是刷得太快没法阅读的。
1.高可用：任何一个节点故障都不应该引起服务不可用；
2.易扩展：具有水平扩展的特性，对不同量级的在线用户数都有应变的能力；
3.高并发低延迟：能支持大量的用户同时收发消息，消息从发出到送达所有在线端的延时在毫秒级；
4.客户端兼容性：新型的应用都是能同时跨多种设备实现消息互通的，比如网页端，手机端和桌面端，甚至智能电视等；
客户端层：处理各种设备的兼容问题，包括对ios，Android，Windows，Web等各种开发平台的语言适配；消息通道的管理维护，包括移动设备上的弱网络管理，断线重连等；保证数据安全，所有上行下行的数据包都需要加解密处理，规避数据泄露或中间人攻击等各种安全风险；
网关接入层：管理大量客户端连接，单个节点可以维护的客户端数量在数十万量级；处理不同类型客户端的协议兼容，由于客户端实现技术的多样性，导致客户端与网关之间底层的数据通信协议存在差异，需要由不同的接入网关做协议转换；处理数据安全逻辑；跨网络的高可用逻辑，网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢)；广播消息的高效下行分发，将收到的广播消息分发到所有连接在本节点上的客户端；
路由层：作为业务层接入的中转，同时承担负载均衡和高可用的作用，单个业务节点处理能力达到瓶颈时更方便的扩容，路由层使业务层扩容对前置网关层完全透明；当一个网络的业务集群出现网络故障时，可以切换到备用网络，保证服务可用性；
业务层：处理聊天室内的业务消息，一个集群内有众多节点，节点角色相互对等，任何一个节点的故障会使整个集群的处理能力下降，但不会引起服务的中断，因为其他节点可以继续接管业务数据包的处理；业务集群同样有多个网络环境的热备，以应对可能出现的区域性网络故障；
1、客户端多样性；目前的应用都存在跨平台的需求，iOS、安卓和PC端，网页端，甚至IOT物联网设备，能连多少是多少，多多益善；但是不同开发平台之间的技术差异性极大，不是所有企业都有这么全的全栈程序猿的；如果团队开发的话单就客户端开发人员就不是几个人可以完成的；
2、数据安全的保证；当前的网络安全形势异常复杂，开发应用时如果不在通信安全上花心思，那你的用户就是在互联网上裸奔；开发者需要针对不同的平台，不同的通信技术实现可靠的安全方案，避免用户数据在传输过程中泄露，避免中间人攻击等安全风险；
3、跨机房网络级的高可用方案，当机房网络出现故障时把责任推给市政施工队或者“网络抽风”已经不流行了，用户需要的是故障无感知；
4、所有环节的单点故障排除，任何硬件和软件都存在故障的可能，我们无法避免应用罢工，那就需要随时准备替补上场；
5、能应对任何用户量级的需求，架构级做到水平扩展的能力，当用户量增长时随时可以通过堆服务器来解决，而不是将架构推到重来；
技术发展到现在已经不流行重复造轮子了，因为轮子的结构越来越复杂，功能性和非功能性的指标要求越来越高；而我们的用户却不会再等我们了。当我们还在画轮子的图纸的时候，竞争对手可能已经把车子都造好，在路上跑了。虽然我们不是非得自己造轮子，但是了解如何完成一个完美的轮子的制作过程和质量标准却是非常有必要的，这也是我前面和你介绍了这么多的原因。