Media Center
用nginx-rtmp的63%代码,增加80%的功能,SRS用到的ST是个什么球?
这次我要讲的是:ST(state-threads)是个什么球? 趁着吃完饭休息会儿,给大家讲讲ST(state-threads),一个四两拨千斤的想法。基于ST的SRS(Simple Rtmp Server)1只用了4.3万行(63%)代码,比nginx-rtmp多了83%的功能,周期缩短100%;而SRS2(Simple Rtmp Server2)只用了6.5万行(95%)代码,比nginx-rtmp多了230%功能。开发周期SRS1(Simple Rtmp Server1)用了1年,SRS2(Simple Rtmp Server2)用了1年;nginx-rtmp发布1.0用了2年。啥都不说了,SRS3(Simple Rtmp Server3)就不再和nginx-rtmp比了,SRS3(Simple Rtmp Server3)和SRS2(Simple Rtmp Server2)比吧~ 如果说代码行数不能说明问题,那再爆料一组数据,SRS1(Simple Rtmp Server1)的注释率是22.1%,而SRS2(Simple Rtmp Server2)的注释率是23.7,nginx-rtmp注释率是3%。可见SRS(Simple Rtmp Server)用ST简化了多少逻辑。nginx-rtmp的6.8万行代码,是去掉了其他模块,只有core和rtmp等必要模块,总共nginx-rtmp有16万行代码。 ST解决的是服务器的最根本问题:如何以最高效率服务多个客户端连接?答案就是nginx的架构,即单线程异步非阻塞socket(没错还有多进程,我们先只考虑如何一个进程最高效);在linux中,就是epoll+send(MSG_DONTWAIT),具体的可以翻翻书柜,epoll早就不是什么新鲜事了。 这个架构可以打个比方,一个快递员在送快递时,假设有4个客户分别在四个完全不同的方向,东家西家南家北家,快递员每家都要送1000个包裹,快递员的货车有限先送东家1000个包裹,东家收了100个候发现家里没有空间了得腾缓冲区出来,快递员只好暂时不管东家了(非阻塞啦),去给西家送了200个还有800个,南家300个还有700个,北家1个还有999个。 接下来肿么办?最快的方式当然是各家的空间腾出来后,快递员用epoll_wait就知道哪些可以继续了,这就是异步啦。这个异步非阻塞是相当高的效率,但是麻烦的地方在于,快递员每次都要登记各家的状态,然后跑到各家去继续送(调用不同的处理函数),路上不仅浪费很多时间,而且维护这些信息非常之麻烦啊!每次都得把路重新计算规划,再跑一边非常需要费脑筋啦。 最简单的方式是不要登记各家状态,每家都派一个快递员啦(创建线程),各家有空间这个快递员马上就继续发,这样是最简单的逻辑;缺点是要做线程同步咯,而且很昂贵啦,没法一下子服务几万个用户。 孙悟空的毫毛可以用在这里,分身术,实际上还是一个快递员,但是在各家那里分个身。好处是不用登记那些信息,各家有空间了立马就开始写;比线程的优势是不用锁,开销小。ST就是分身术,虚拟线程,即用户空间线程协程,类似goroutine,或者C#的纤程。 协程完全是不同于进程和线程的一套写代码思路,解决问题的思路不一样,当然结果是不一样的啦。在处理rtmp的edge,以及http-flv的hstrs(http stream trigger rtmp source)时,涉及到多个线程交互,这种就相当于两个异步状态空间相乘,那个是相当之复杂的。这是为何nginx-rtmp实现RTMP比较费劲,要实现RTMP-EDGE,以及HTTP-FLV、HSTRS是非常难的事情。 关于ST更多信息,请参考:http://blog.csdn.net/win_lin/article/details/8242653 欢迎小伙伴们使用我们的开源流媒体软件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号