社区微信群开通啦,扫一扫抢先加入社区官方微信群
社区微信群
和传统页面,点播业务的 CDN 只有下行分发不同。对于一些秀场,游戏类的直播场景中主播一般是分散在全国各地的,所以直播架构中是分为上行汇聚和下行分发两套网络。而对一些现场活动,赛事制作方的直播,更多的是业务方提供一个源站,由 CDN 去拉取后进行分发。
主播推流模式
回源拉流模式
下行观看流程
下行观看流程和传统 CDN 类似,会有直播数据 Cache,由于实效性问题, Cache 时间一般是直播最近几秒的数据,一般多采用内存 Cache 的方式。因此直播业务的回源率比传统 CDN 要高很多。
在直播中,Cache 时长,主播观众分布和观看人数。
对于 CDN 来说,不可能只使用一个汇聚核心:
因此,直播一般会使用多汇聚核心的架构,下面介绍两种常用的网络架构方式。
架构 1 的思路就是保证每个汇聚核心都有流,下行边缘无论到哪个核心都能拉到流。好处就是不需要使用数据库去记录流是推到哪个核心的,从架构上来说比较简单粗暴,但是存在以下问题:
综上,这种架构不适合太多的核心,更适合多选取中转节点的方式来保证质量
在这个网络架构中,基本思路:下行节点是可以进行选优的,即下行边缘将一个汇聚核心作为主核心,只有当链路异常时才去备用汇聚核心拉流
架构 2 的思路就是链路选优,上行到一个链路最优的核心,下行也到一个链路最优的核心,两个核心之间使用专线打通,以保证质量。一般情况下,国内最多使用 3 个核心就能覆盖国内主要区域和运营商,5 个核心就能基本覆盖全国所有边缘节点。核心之间可以使用专线为主,公网为辅的方式,这样对骨干网异常也能起到一定的容错性
相对网络架构1,网络架构2更能保证直播的质量,但是存在一些技术难点
当然核心间互拉也可以改成互推的方式,这样可以省去一些流生命周期管理的麻烦,但是和网络架构1一样会浪费资源
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!