單進程SRS支持7.5k并發，如果單機需要單機100K并發，可以使用多進程SRS，即SRS-DOLPHIN。目前測試SRS-DOLPHIN的測試數據是20K并發，理論上多進程的擴展性可以到達任意并發，只要你的CPU和網卡還有交換機夠。而SRS-DOLPHIN不僅僅是高并發，還可以做容錯，提高穩定性。只需要修改啟動命令，兼容單進程的配置文件。

SRS為何做進程？有三個主要的因素：

100k目標：萬兆和多萬兆網絡會在這幾年使用起來，而SRS單進程對于網絡擴展性不好，多進程是支持富余硬件資源最好的方式。就算是幾個千兆網卡，多進程的效率比單進程也更高，涉及到linux的中斷處理。

邊緣熱備：如果邊緣掛掉了，客戶端就斷開，譬如7.5k個用戶都在一個邊緣上，那受影響的就是7.5k。如果邊緣使用srs-dolphin，可以每個SRS只支持2.5k，3個進程支持7.5k，這樣每個SRS掛掉只影響2.5k用戶。

最簡多進程方案：srs-dolphin是由外國的一個牛逼的朋友提供的一個多進程方案，使用和部署和單進程SRS一樣，只是啟動的命令不太一樣而已，配置文件都一樣。srs-dolphin更像是個進程管理器和容器，實現方式還是SRS單進程疊加。SRS會支持任何功能，只要能找到最簡單方案。

SRS-DOLPHIN是流媒體邊緣的最佳方案，現在有幾個多進程的方案：

nginx：若SRS能輸出HTTP-FLV，那么可以啟動幾個SRS邊緣，再啟動一個nginx反向代理，這樣可以實現多進程，相當于一個本地小集群。粗步測試數據是，10k并發時nginx占用350%CPU。

go-sharp：這個是srs org提供的一個go實現的HTTP FLV反向代理，替代nginx的方案，主要支持SRS檢測，負載均衡。粗步測試數據是，10k并發時go-sharp占用300%CPU。

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

總結

以上是生活随笔為你收集整理的SRS-DOLPHIN的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。