如何在 SRS 上启用多线程

0
投票

首先，SRS 是一个单线程媒体服务器，高性能所以你通常不需要多线程。因为多线程不是灵丹妙药，甚至不是铜弹，所以它是问题本身，而不是问题的解决方案。

请指出您的 SRS 服务器性能低下的原因，而不是切换到多线程模型。如果你只是想像多线程一样酷，请不要使用SRS，因为SRS致力于支持业务，而不是为了酷。

为什么不多线程？

我不喜欢多线程，因为它真的会导致很多问题：

如果这不方便你，请做一些关于 REDIS 的研究，它也是单线程服务器。

其实很简单：因为媒体服务器的瓶颈不是CPU，而是IO或网络，请看State Threads for Internet Applications。这就是为什么 SRS 使用 state-threads 协程作为网络框架的原因。

比如说，如果你想支持1000个播放器，并且每个播放器以2Mbps的速度观看一个RTMP流，那么输出带宽就是2Gbps。您的 AWS/腾讯云服务器支持 2Gbps 带宽吗？或者你想支付 2Gbps 的费用，大约是每秒 0.02 美元，每小时 72 美元，或者每天 1728 美元？

如果是，SRS 只需要大约 30~50% 的 CPU 来向这些客户端提供实时流，因此您仍然不需要多线程服务器。

最终，监控 SRS 真的很容易，因为如果 CPU >80%，负载太高，你应该做一些事情来扩展你的 SRS 服务器。

其实SRS可以让你通过直播集群进行横向扩展，请阅读origin集群和edge集群，它可以让你搭建一个CDN系统。

如果你在单个节点上部署 SRS 集群，那么你的所有 CPU 都会很忙，这与多线程服务器完全相同甚至更好。

这实际上是媒体服务器的负载平衡问题，请阅读负载平衡流媒体服务器了解详情。

并且，我们正在为 WebRTC 和 SRT 开发一个新的集群，请参阅#3138，我们将在 SRS 6.0 发布它。

是的！我们确实对多线程做了很多研究，请参阅#2188。老实说，我们发现它既不是媒体服务器的必要架构，也不是好的架构。

但是，我们细化了SRS的结构，支持多线程，所以SRS运行的是两个线程，而不是真正的单线程。

我们可能会使用多线程进行转码和写入磁盘来解决磁盘阻塞问题。

但是，这并不意味着我们将结构更改为多线程模型，同样，我们想要构建一个媒体服务器，而不是为了酷。

虽然SRS的单线程和集群模式有很多好处，但也有一些局限性你应该知道。

需要更多的实例来维护。如果手动或者K8s部署SRS，实例会比较多，每个都是一个容器或者K8s pod。 K8s 非常擅长管理这些 Pod，但是你需要学习 K8s。如果通过 docker 启动 SRS，您应该为主机服务器中的多个容器设计端口和角色。
系统的目标不是像 YouTube、Twitch、AWS 或腾讯云那样支持数十亿流和观众的非常大的系统。如果您想构建一个伟大而庞大的系统，请不要使用 SRS。
SRS 不擅长创建跨国家和大陆的分布式系统，也不擅长创建强大的传输算法以在甚至 60% 损失的网络中工作。如果你想构建一个庞大的 PaaS 系统，请不要使用 SRS。

SRS专为中小型媒体系统设计，支持小于10k连接，使用CDN或AWS或腾讯云等PaaS平台扩展大并发能力，与其他客户端开源项目如FFmpeg、OBS、VLC、 WebRTC 等

SRS是一个单线程媒体服务器，但并不意味着单线程模型不能横向扩展，而是我们有直播，WebRTC和SRT的集群解决方案，这比多线程模型要好得多。