srs之简单优势

本文转载

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热备中最牛逼的一个方案~