上几篇介绍了怎样实现一个百万级别的语音聊天室，本篇将介绍直播平台的设计。开始分享这个项目虽然有点迟疑，因为我所参与的直播平台跟业界常用的方案不太一样。但是仔细想想，架构设计原本就是在各类条件约束下的因地制宜，没有绝对的正确和错误（小兔情感挽回老师 微信：ke2004578），合适才是关键。
我们是国外做直播相对比较早的团队，也缺少一些行业通用方案的参考，因此好多地方是自己通过踩坑摸索下来的。因为最开始我们产品只支持语音聊天，后来随着直播业务（娱乐直播、游戏直播）的普及，才开始支持视频直播，所以最朴实的看法就是，直接把语音服务的构架拿过来用。
上篇介绍了语音聊天室的完整构架，我们的设计就从这儿开始。视频服务可以用这些构架吗？答案是肯定的。把上图中的语音数据替换成视频数据就可以了，唯一的不同是语音聊天室多个用户可以同时说话，但是直播平台就只能有一个主播。
但是，随着业务不断下降，问题开始出现：一个SET内的卧室数目抵达了困局。为什么呢？这要从语音服务器的实现说起。
如图所示，每个语音服务器为每位屋子维护6个语音通道（采用循环队列实现），其中5个通道分别缓存5个用户的语音数据，第6个是混缩通道。没错，是5个用户，聊天室的设计就是最多只支持5个用户同时说话，因为同时说话的人再多都会听不清楚。那其他人想说话怎样办？一般的做法是聊天室的抢麦或则用户多长时间不说话就手动舍弃通道，或者象LOL此类游戏团队设计就只有5个人。混音通道实际上就是把5个通道的数据按照时间次序放在一起（当然还有一些其他处理），听众收到的是混缩通道的数据。
视频服务器由于每位卧室只有一个主播，因此只须要维护一个视频数据通道，实现上与语音服务器类似。按理说，视频服务器应当更简单才对，但是却有别的问题。
之前说过，语音服务器是根据SET来布署的，一个SET包含多个语音服务器，房间分布在一个SET内的机器上。因此一般一个卧室会分布到多台语音服务器，这样主要是为了用户的就近接入。那SET内的卧室数受哪些阻碍呢？
之前没有介绍的一个细节是，下图所示，如果一个卧室分布在多台语音服务器，这些语音服务器上都须要维护这个屋子的6个语音通道（为什么不是只维护混缩通道，大家自己思索），因此屋子数的阻碍主要在于单台服务器的显存大小。
因为语音数据是太小的，一个包大约300多字节，6个语音通道占用的显存大约几M，一台4G显存的机器就可以承载上千个卧室。按照之前的估算一个SET 10台机器可以承载20万的用户，上千个卧室几乎是不可能的，因此对于语音服务，内存的困局是不存在的。
但是对于视频服务就不一样了，视频数据但是很大的，一帧的数据有时候可以达到几M， 1个数据通道都可能占用几十甚至上百M的显存。因此单服务器可承载的卧室数可能只有一百个，也就是说单SET的卧室数最多只能有一百个，这里就是困局所在。
大家注意了，这个困局是难以通过平行扩充降低机器来解决的，因为每台机器都深受这个限制（当然可以给每台机器加显存来解决，但是这些做法一方面降低了成本，另一方面降低了故障的机率）。这是一个系统构架造成的问题美女视频直播怎样过性生活技巧，解决方式可能好多，例如革除分SET的构架，或者把SET机器数降低等等。可以说，这个问题把我们从最开始闭门造车的野路子拉回了业界的通用标准。
做过直播的朋友应当对前面的图都太熟悉，它是一个典型的直播平台的构架图。这个图跟我们最开始的构架有一个最本质的区别是，我们采用了他人的CDN。为什么要加“别人”？因为我们之前实际上是在尝试做自己的CDN来实现数据的分发。但是这条路走出来是个无底洞，我们没有他人的资源丰富和专业。因此，上面的构架中，我们只负责生产数据，我们维护主播上传的视频数据，并把视频资源信息上报给回源服务器。用户打开直播时，先去CDN恳求数据，如果CDN没有数据，就会到回源服务器查找资源地址，并向资源所在的视频服务器恳求数据返回用户。下次用户打开视频的时侯，CDN就直接从自己维护的数据通道中获取视频了。
本篇主要介绍了视频服务构架演化的过程，描述了从最开始仿效语音服务的构架，到面临构架困局时，转而采用目前业界通用的构架的思路历程。架构设计跟项目所处的时代背景和阶段密切相关，每个阶段都有其局限性，不能由于技术发展而完全否定原先的设计思路，现在所谓的业界标准也是从一次次的踩坑中走出来的。
