SRS进入20K时代，不仅仅是并发

单进程SRS支持7.5k并发，如果单机需要单机100K并发，可以使用多进程SRS，即SRS-DOLPHIN。目前测试SRS-DOLPHIN的测试数据是20K并发，理论上多进程的扩展性可以到达任意并发，只要你的CPU和网卡还有交换机够。而SRS-DOLPHIN不仅仅是高并发，还可以做容错，提高稳定性。只需要修改启动命令，兼容单进程的配置文件。

SRS为何做进程？有三个主要的因素：

1. 100k目标：万兆和多万兆网络会在这几年使用起来，而SRS单进程对于网络扩展性不好，多进程是支持富余硬件资源最好的方式。就算是几个千兆网卡，多进程的效率比单进程也更高，涉及到linux的中断处理。

2. 边缘热备：如果边缘挂掉了，客户端就断开，譬如7.5k个用户都在一个边缘上，那受影响的就是7.5k。如果边缘使用srs-dolphin，可以每个SRS只支持2.5k，3个进程支持7.5k，这样每个SRS挂掉只影响2.5k用户。

3. 最简多进程方案：srs-dolphin是由外国的一个牛逼的朋友提供的一个多进程方案，使用和部署和单进程SRS一样，只是启动的命令不太一样而已，配置文件都一样。srs-dolphin更像是个进程管理器和容器，实现方式还是SRS单进程叠加。SRS会支持任何功能，只要能找到最简单方案。

SRS-DOLPHIN是流媒体边缘的最佳方案，现在有几个多进程的方案：

1. nginx：若SRS能输出HTTP-FLV，那么可以启动几个SRS边缘，再启动一个nginx反向代理，这样可以实现多进程，相当于一个本地小集群。粗步测试数据是，10k并发时nginx占用350%CPU。

2. go-sharp：这个是srs org提供的一个go实现的HTTP FLV反向代理，替代nginx的方案，主要支持SRS检测，负载均衡。粗步测试数据是，10k并发时go-sharp占用300%CPU。

3. srs-dolphin：这个是SRS多进程方案，支持基于SRS的RTMP和HTTP的多进程方案，不仅仅是HTTP FLV。粗步测试数据是，20k并发时srs-dolphin占用320%CPU。
   

为何SRS-DOLPHIN可以做到一倍的性能提升？因为SRS-DOLPHIN实现的是TCP层次的代理，不解析协议直接转发。

SRS-DOLPHIN的弱点就是不解析协议，所以无法做源站多进程。但是从业务逻辑上讲，源站7.5k并发足够了；如果一定要做源站多进程，譬如流就是很多时，有个朋友的情况就是100k个流，那么源站多进程也扛不住，必须使用多源站，也就是多个源站服务器，配合边缘路由实现。边缘路由也就是一个边缘SRS，知道一组源站SRS，知道哪个流应该回哪个源站；边缘路由不适合做成开源，涉及到的业务逻辑居多；观止已经在计划这个产品了。

下面是SRS-DOLPHIN在20k的测试数据：

GO-SHARP参考：https://github.com/simple-rtmp-server/go-sharp

SRS-DOLPHIN请参考：https://github.com/simple-rtmp-server/srs-dolphin