1.数据量大

　　视频直播第一个问题就是数据量太大，假设想YY这样一个房间假设有5000人同时观看的话，假设视频数据每秒50K(实践数据可能比这个要大)那么这个数据需要50*5000=250000K.那么这么多数据等于多少MB答主默默的掏出了计算器25000/1024=244MB，244*8=1952Mb.对的没错单单这一个房间每秒消耗的流量就达到1952Mb这是相当惊人的(答主不经回头看看是不是哪里搞错了)。而且这只是一个房间，高峰时期假设有300w人同时在线上吹牛逼我们用同样的方法来算算没秒走出去的带宽达到1144Gbps,这简直就是凶残。

　　2.低延迟

　　所谓直播要的就是及时性，比较直播世界杯你比电视机慢了几十秒，那么基本上可以说你这个不可用了。面对变大的流量和很高的并发又有一个棘手的问题就是延迟还必须要低，这个必须走硬件来扛了?其实差不多。

　　3.网络环境复杂

　　国内ISP比较多，有些用户在电信 有些用户在网通 移动和联通 等等。这些用户都要同等对待。跨ISP的问题很多，网速很慢。一般有两种解决办法，一种是购买多线机房，也就是大家说的bgp机房，这个比较省心但是有个缺点价格嘛……少年掏银子吧!!!!第二种就是自己搭建网关转发多ISP数据。

　　4.故障转移不好做

　　对比web前面有智能DNS，后面有LVS等的高可用，web的故障转移有一整套的解决方案，甚至做到了用户无感知。视频直播的故障转移是比较困难的。

　　那么面多这些棘手的问题如果解决?

　　1.首先是流量的问题

　　流量显然不能只是从服务器转发走的︶︿︶这样白花花的银子都走了。好在一个房间内的视频对每个人都一样的，所以用户之间可以共享收到的数据，可以给用户机器之间P2P。那么谁和谁用户之间共享这个数据?还有P2P前需要做内网渗透这个打穿防火墙的操作是需要时间的，如果保证低延迟?如果和我共享数据的人下线了那么我的数据P2P就断了，如何处理?这些都是问题哇!!

　　2.低延迟

　　这个语言两点。第一点服务器的处理数据要乱快，必须快。加上这又是IO密集型的所以说白了就是机器够强带宽够大。第二点如果采用P2P需要算法保证数据共享的合理性，最后从服务器出去的数据和P2P扛的数据可以合理的达到一个平衡。

　　3.高可用

　　这个部分我也不清楚。来扯下。首先用户的状态必须单独分开存放当缓存的服务器上面，缓存服务器多实例主从必须做。接入服务器把用户的数据接入进来，提交给其他服务器比如跨网关的服务器转发?如果接入或者其他服务器挂了如何保证数据可用?如果用TCP客户端可能已经断开了，需要掉线重连了。