Media Center
nginx架构太复杂,流服务器还可以更简单吗?
SRS(Simple Rtmp Sever)最关键是Simple,最简单的方案就是最佳方案;这个文章记录了SRS(Simple Rtmp Server)关键的Simple方案,也就是50%代码完成200%功能,100%代码完成400%功能的要点。 State Threads ST带来的问题简化,在一个状态空间时至少一个数量级;多个状态空间时就是百个数量级,譬如edge回源,http-flv和hstrs。在网络服务器中st的思路是与众不同,也是很巧妙的思路。 SRS(Simple Rtmp Sever)是单进程使用epoll进行异步socket操作的高性能服务器,架构和nginx同源(同为非阻塞、异步、单线程),除了nginx是多进程SRS(Simple Rtmp Sever)是单进程之外。 SRS(Simple Rtmp Sever)没有直接使用epoll进行状态处理,而是使用了协程库state-threads,简称st(详细介绍可以看文章:高性能、高并发、高扩展性和可读性的网络服务器架构:StateThreads)。 关于setjmp和longjmp,以及为何st必须自己分配stack,参考st(state-threads) coroutine和setjmp/longjmp的关系 关于st如何分配栈,以及进行协程切换,以及协程的生命周期,参考:st(state-threads)线程和栈分析 ST参考:ST Multiple Processes SRS(Simple Rtmp Server)支持多进程吗?不支持。SRS(Simple Rtmp Server)能支持多进程吗?可以的。简单讲有几个因素不支持多进程: 1.单进程9k并发够用了。 2.多进程比单进程还是麻烦点。 3.RTMP302会更方便,只是需要播放器支持。 在SRS(Simple Rtmp Sever)1时,杰哥就提出过多进程的方案,这个方案比任何流媒体服务器多进程方案都要牛逼!简单讲,就是master进程作为源站origin服务器,然后fork多个边缘edge服务器,这些edge服务器通过lo网卡回本地的origin。这个方案牛逼的地方包括: 1.没有引入新的角色,只是fork进程,使用SRS(Simple Rtmp Sever)本来的origin-edge结构合并回源。 2.不transfer fd,也就是edge直接处理连接,不用在进程间调度。 如果你觉得9k的并发还不够,建议自己使用杰哥提供的这个多进程方案。 HLS Fault Tolerance Backup 关于HLS热备,在流媒体中是比较难以处理的一个问题,具体可以参考hls。所谓HLS热备,是指编码器(它自己可以热备)输出两路相同的RTMP流给两个不同地方的机房的流媒体服务器,然后这两个服务器生成的切片一样,这样任何一个机房宕机都不会影响hls流的生成。 比较典型的做法,是利用ATC时间戳,然后按照指定的规则生成切片。这样两个服务器输出的切片完全一样。 悟空提出了更好的方案,即使用standby方案替代完全热备: 1.编码器输出相同的流给异地机房的两个流媒体服务器,两个服务器之间保持通信。 2.两个服务器一个时刻只有一个输出HLS切片,另外一个standby。 3.当另外一个服务器挂掉时,standby的立刻开始切片。 4.两个服务器的切片都输出到一个存储。 这个方案确实很巧妙,使用另外不同的思路解决切片同步的问题。虽然在服务器切换时会有点切片间隙或不同步,但实际上并不会有大的影响。这点点瑕疵,至少简化了几个数量级的难度,是我见过所有HLS热备中最牛逼的一个方案~ 欢迎小伙伴们使用我们的开源流媒体软件SRS(Simple Rtmp Server)。开源不够用,需要定制怎么办?亲,您可尝试关注观止商业版流媒体平台产品哦,商业版产品会领先开源版本12个月左右,包含编转码器、播控、Web P2P等更多功能,啥都有~
北京观止创想科技有限公司
TEL: 010-8233 1879 FAX: 010-8233 1989
EMAIL: chnvideo@chnvideo.com ADD: 北京市海淀区知春路1号学院国际大厦801
Copyright © 2014 BRAVO观止创想,保留所有权利 京ICP备12047633号