SRS進入20K時代，不僅僅是併發
單程序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