mediamtx 如何用读副本架构横向扩展观众负载origin、replica 与负载均衡配置【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx当同一台 MediaMTX 需要同时服务大量读者readers或发布者时流媒体性能可能因底层硬件瓶颈而下降。MediaMTX 不做重编码这类瓶颈几乎总是出在服务器与读者之间的带宽上。官方给出的缓解方式是横向扩展部署多台协同工作的 MediaMTX 实例把观众负载均匀分摊出去。其中主推的技术是读副本read replicas再实例化若干台 MediaMTX 作为读副本它们从一台origin源站MediaMTX 实例拉取流分发给用户用户连接和请求由负载均衡器分发到各副本发布者则始终向 origin 发布。本文按 横向扩展文档 描述的完整路径讲清楚 origin、读副本、负载均衡器三者的配置和验证方式。整体角色与负载均衡器选型三类角色各自承担的工作角色职责origin 实例接收发布者发布的流读副本实例通过代理路径proxy path从 origin 拉流向用户提供流负载均衡器把观众按协议分发到各读副本负载均衡器的类型取决于观众使用的协议这是文档明确要求区分的观众使用 RTSP、RTMP、SRT 时负载均衡器必须是Layer 4 LB观众使用 HLS 和 WebRTC 时必须是Layer 7 LB 并开启 sticky sessions粘性会话因为单个 HLS 或 WebRTC 会话由多个 HTTP 请求组成同一用户的请求必须被转发到同一台副本。准备条件至少三台机器或等价资源一台运行 origin若干台运行读副本一台或多台运行负载均衡器各机器可运行 Docker使用官方镜像bluenviron/mediamtx:1各机器之间可互通以下默认端口见 mediamtx.yml 中的默认值RTSP8554、RTMP1935、HLS8888、WebRTC8889、SRT8890。第一步启动 origin 实例在承载 origin 的机器上执行docker run -d \ --name mediamtx \ --restart always \ --network host \ bluenviron/mediamtx:1启动后发布者按平常方式把流发布到 origin 的8554端口即可无需其他改动。第二步配置读副本在每台承载读副本的机器上创建 MediaMTX 配置文件mediamtx.ymlwebrtcLocalUDPAddress: webrtcICEServers2: - url: stun:stun.l.google.com:19302 paths: ~^(.)$: source: rtsp://dns-of-origin:8554/$G1 sourceOnDemand: yes然后把dns-of-origin替换为 origin 机器的 DNS 或 IP启动 MediaMTXdocker run -d \ --name mediamtx \ --restart always \ --network host \ -v $PWD/mediamtx.yml:/mediamtx.yml \ bluenviron/mediamtx:1这段配置的依据见 代理请求文档路径名使用正则~^(.)$时$G1会被替换为正则捕获的第一个分组因此任何路径的读取请求例如rtsp://副本:8554/a都会被代理到 origin 的同名路径。sourceOnDemand: yes使副本按需拉流。配置中有两个针对 WebRTC 读者的要求需要注意把webrtcLocalUDPAddress置空即文档中的空值写法表示禁用静态 UDP 端口同时不启用webrtcLocalTCPAddress通过webrtcICEServers2启用一个 STUN 服务器。原因见 WebRTC 连接问题文档服务器前面有 NAT 或负载均衡器时静态 UDP/TCP 端口方式难以建立 peer connection应改用随机 UDP 端口加打洞需要 STUN 服务器必要时再升级到 TURN。如果你的观众全部使用 RTSP/RTMP/SRT/HLS这两行 WebRTC 相关配置可以删掉。第三步配置负载均衡器文档给出的通用示例使用 Traefik 作为负载均衡器。在承载负载均衡器的机器上创建主配置traefik.ymlentryPoints: rtsp: address: :8554 rtmp: address: :1935 srt: address: :8890/udp # SRT usually uses UDP hls: address: :8888 webrtc: address: :8889 providers: file: filename: /etc/traefik/dynamic_conf.yml watch: true再创建动态配置dynamic_conf.yml其中按上文规则区分 L4 与 L7tcp: routers: rtsp-router: rule: HostSNI(*) entryPoints: [rtsp] service: rtsp-service rtmp-router: rule: HostSNI(*) entryPoints: [rtmp] service: rtmp-service services: rtsp-service: loadBalancer: servers: - address: replica-1-ip:8554 - address: replica-2-ip:8554 rtmp-service: loadBalancer: servers: - address: replica-1-ip:1935 - address: replica-2-ip:1935 udp: routers: srt-router: entryPoints: [srt] service: srt-service services: srt-service: loadBalancer: servers: - address: replica-1-ip:8890 - address: replica-2-ip:8890 http: routers: hls-router: rule: PathPrefix(/) entryPoints: [hls] service: hls-service webrtc-router: rule: PathPrefix(/) entryPoints: [webrtc] service: webrtc-service services: hls-service: loadBalancer: sticky: cookie: name: SERVERID servers: - url: http://replica-1-ip:8888 - url: http://replica-2-ip:8888 webrtc-service: loadBalancer: sticky: cookie: name: SERVERID servers: - url: http://replica-1-ip:8889 - url: http://replica-2-ip:8889把replica-1-ip、replica-2-ip替换为实际读副本机器的 IP副本更多时在对应servers列表中继续追加。注意http段HLS、WebRTC使用了sticky: cookie粘性会话而tcp/udp段没有这正对应上文 L7/L4 的区别。启动 Traefikdocker run -d \ --name traefik \ --restart always \ --network host \ -v $PWD/traefik.yml:/etc/traefik/traefik.yml \ -v $PWD/dynamic_conf.yml:/etc/traefik/dynamic_conf.yml \ traefik:v3.6.14验证通过负载均衡器读取流完成以上三步后按文档的验收方式使用负载均衡器机器的 IP 或 DNS配合任意协议读取流即可。也就是说观众把地址从 origin 换成负载均衡器地址端口不变8554 / 1935 / 8890 / 8888 / 8889能正常拉到流就说明读副本链路已通。如果你不需要完整的负载均衡器文档也给出了一条可选简化路径把一个域名同时指向所有读副本的 IP用该域名读流。但要清楚它的局限IP 顺序是否随机取决于 DNS 服务商客户端是否随机选择某个 IP取决于客户端行为官方没有提供额外的均衡保证。可选分支AWS 上的等价实现如果你的环境在 AWS 上文档给出了一整套对应云服务的实现安全组、NLB/ALB、Target Group、自动扩缩容组要点如下创建三个安全组mediamtx-load-balancer入站 All TCP All UDP来源0.0.0.0/0、mediamtx-read-replicasSSH 限管理员 IP 段All TCP / All UDP 来源指向mediamtx-load-balancer安全组、mediamtx-originSSH 限管理员 IP 段Custom TCP8554和 All UDP 来源指向mediamtx-read-replicas安全组即只允许读副本从 origin 拉流另加发布者的 IP 段的 Custom TCP8554与 All UDP 规则供发布者推流。这个安全组划分直接体现了架构边界观众流量只到读副本副本流量到 origin发布者流量直接到 origin。在 origin 的 EC2 实例上通过 User data 安装 Docker 并以--network host运行bluenviron/mediamtx:1为读副本创建 Launch template其 User data 写入与上文相同的mediamtx.yml其中dns-of-origin替换为 origin 实例的私有 DNS同样以 host 网络运行。为每个协议/端口组合各建一个 Target grouptarget type 选 Instancesmediamtx-read-replicas-8554TCP8554RTSP健康检查 TCPmediamtx-read-replicas-1935TCP1935RTMP健康检查 TCPmediamtx-read-replicas-8890UDP8890SRT健康检查协议 TCP高级设置中把健康检查端口覆盖为8554mediamtx-read-replicas-8888HTTP8888HLS健康检查 HTTP成功码404mediamtx-read-replicas-8889HTTP8889WebRTC健康检查 HTTP成功码404。注意 HLS 与 WebRTC 的健康检查成功码设为404——这些端点在没有会话时返回 404这被视为健康状态。对8888和8889两个 Target group 打开 stickiness对应 L7 粘性会话要求。创建两个负载均衡器并共享mediamtx-load-balancer安全组Network Load BalancerTCP8554→ RTSP Target groupTCP1935→ RTMP Target groupUDP8890→ SRT Target groupApplication Load BalancerHTTP8888→ HLS Target groupHTTP8889→ WebRTC Target group。创建读副本的 Auto scaling group使用上面的 Launch template在 Load balancing 一节选择 Attach to an existing load balancer 并勾选全部 5 个 Target group在 Group size 的 Desired capacity 中设定实例数。验收方式同样来自文档用 Network Load Balancer 的 DNS 以 RTSP、RTMP、SRT 读流用 Application Load Balancer 的 DNS 以 HLS、WebRTC 读流。如果观众只使用单一协议例如仅 WebRTC可以只开放对应端口8889并只创建对应的负载均衡器Application load balancer其余步骤可省略。已知限制文档对读副本方案明确列出了三条限制规划时需要考虑突发流量峰值可以通过调整读副本数量来应对但调整不是即时的依赖自动扩缩容策略或人工操作期间可能出现短暂的性能下降读副本数量增加可能使副本与 origin 之间的带宽饱和形成新的瓶颈每台读副本都需要一台专用且可能昂贵的机器。针对 HLS 场景文档还提到另一种替代思路在 MediaMTX 的 HLS 服务器前面挂 CDN。但它的代价是只有 HLS 协议可用、Low-Latency HLS 播放列表无法缓存通常意味着要禁用 LL-HLS 变体、引入明显延迟、且 MediaMTX 标准鉴权机制不可用。如果观众需要低延迟或多种协议读副本仍是文档中的主路径。【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 mediamtx 如何用读副本架构横向扩展观众负载？origin、replica 与负载均衡配置
mediamtx 如何用读副本架构横向扩展观众负载origin、replica 与负载均衡配置【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx当同一台 MediaMTX 需要同时服务大量读者readers或发布者时流媒体性能可能因底层硬件瓶颈而下降。MediaMTX 不做重编码这类瓶颈几乎总是出在服务器与读者之间的带宽上。官方给出的缓解方式是横向扩展部署多台协同工作的 MediaMTX 实例把观众负载均匀分摊出去。其中主推的技术是读副本read replicas再实例化若干台 MediaMTX 作为读副本它们从一台origin源站MediaMTX 实例拉取流分发给用户用户连接和请求由负载均衡器分发到各副本发布者则始终向 origin 发布。本文按 横向扩展文档 描述的完整路径讲清楚 origin、读副本、负载均衡器三者的配置和验证方式。整体角色与负载均衡器选型三类角色各自承担的工作角色职责origin 实例接收发布者发布的流读副本实例通过代理路径proxy path从 origin 拉流向用户提供流负载均衡器把观众按协议分发到各读副本负载均衡器的类型取决于观众使用的协议这是文档明确要求区分的观众使用 RTSP、RTMP、SRT 时负载均衡器必须是Layer 4 LB观众使用 HLS 和 WebRTC 时必须是Layer 7 LB 并开启 sticky sessions粘性会话因为单个 HLS 或 WebRTC 会话由多个 HTTP 请求组成同一用户的请求必须被转发到同一台副本。准备条件至少三台机器或等价资源一台运行 origin若干台运行读副本一台或多台运行负载均衡器各机器可运行 Docker使用官方镜像bluenviron/mediamtx:1各机器之间可互通以下默认端口见 mediamtx.yml 中的默认值RTSP8554、RTMP1935、HLS8888、WebRTC8889、SRT8890。第一步启动 origin 实例在承载 origin 的机器上执行docker run -d \ --name mediamtx \ --restart always \ --network host \ bluenviron/mediamtx:1启动后发布者按平常方式把流发布到 origin 的8554端口即可无需其他改动。第二步配置读副本在每台承载读副本的机器上创建 MediaMTX 配置文件mediamtx.ymlwebrtcLocalUDPAddress: webrtcICEServers2: - url: stun:stun.l.google.com:19302 paths: ~^(.)$: source: rtsp://dns-of-origin:8554/$G1 sourceOnDemand: yes然后把dns-of-origin替换为 origin 机器的 DNS 或 IP启动 MediaMTXdocker run -d \ --name mediamtx \ --restart always \ --network host \ -v $PWD/mediamtx.yml:/mediamtx.yml \ bluenviron/mediamtx:1这段配置的依据见 代理请求文档路径名使用正则~^(.)$时$G1会被替换为正则捕获的第一个分组因此任何路径的读取请求例如rtsp://副本:8554/a都会被代理到 origin 的同名路径。sourceOnDemand: yes使副本按需拉流。配置中有两个针对 WebRTC 读者的要求需要注意把webrtcLocalUDPAddress置空即文档中的空值写法表示禁用静态 UDP 端口同时不启用webrtcLocalTCPAddress通过webrtcICEServers2启用一个 STUN 服务器。原因见 WebRTC 连接问题文档服务器前面有 NAT 或负载均衡器时静态 UDP/TCP 端口方式难以建立 peer connection应改用随机 UDP 端口加打洞需要 STUN 服务器必要时再升级到 TURN。如果你的观众全部使用 RTSP/RTMP/SRT/HLS这两行 WebRTC 相关配置可以删掉。第三步配置负载均衡器文档给出的通用示例使用 Traefik 作为负载均衡器。在承载负载均衡器的机器上创建主配置traefik.ymlentryPoints: rtsp: address: :8554 rtmp: address: :1935 srt: address: :8890/udp # SRT usually uses UDP hls: address: :8888 webrtc: address: :8889 providers: file: filename: /etc/traefik/dynamic_conf.yml watch: true再创建动态配置dynamic_conf.yml其中按上文规则区分 L4 与 L7tcp: routers: rtsp-router: rule: HostSNI(*) entryPoints: [rtsp] service: rtsp-service rtmp-router: rule: HostSNI(*) entryPoints: [rtmp] service: rtmp-service services: rtsp-service: loadBalancer: servers: - address: replica-1-ip:8554 - address: replica-2-ip:8554 rtmp-service: loadBalancer: servers: - address: replica-1-ip:1935 - address: replica-2-ip:1935 udp: routers: srt-router: entryPoints: [srt] service: srt-service services: srt-service: loadBalancer: servers: - address: replica-1-ip:8890 - address: replica-2-ip:8890 http: routers: hls-router: rule: PathPrefix(/) entryPoints: [hls] service: hls-service webrtc-router: rule: PathPrefix(/) entryPoints: [webrtc] service: webrtc-service services: hls-service: loadBalancer: sticky: cookie: name: SERVERID servers: - url: http://replica-1-ip:8888 - url: http://replica-2-ip:8888 webrtc-service: loadBalancer: sticky: cookie: name: SERVERID servers: - url: http://replica-1-ip:8889 - url: http://replica-2-ip:8889把replica-1-ip、replica-2-ip替换为实际读副本机器的 IP副本更多时在对应servers列表中继续追加。注意http段HLS、WebRTC使用了sticky: cookie粘性会话而tcp/udp段没有这正对应上文 L7/L4 的区别。启动 Traefikdocker run -d \ --name traefik \ --restart always \ --network host \ -v $PWD/traefik.yml:/etc/traefik/traefik.yml \ -v $PWD/dynamic_conf.yml:/etc/traefik/dynamic_conf.yml \ traefik:v3.6.14验证通过负载均衡器读取流完成以上三步后按文档的验收方式使用负载均衡器机器的 IP 或 DNS配合任意协议读取流即可。也就是说观众把地址从 origin 换成负载均衡器地址端口不变8554 / 1935 / 8890 / 8888 / 8889能正常拉到流就说明读副本链路已通。如果你不需要完整的负载均衡器文档也给出了一条可选简化路径把一个域名同时指向所有读副本的 IP用该域名读流。但要清楚它的局限IP 顺序是否随机取决于 DNS 服务商客户端是否随机选择某个 IP取决于客户端行为官方没有提供额外的均衡保证。可选分支AWS 上的等价实现如果你的环境在 AWS 上文档给出了一整套对应云服务的实现安全组、NLB/ALB、Target Group、自动扩缩容组要点如下创建三个安全组mediamtx-load-balancer入站 All TCP All UDP来源0.0.0.0/0、mediamtx-read-replicasSSH 限管理员 IP 段All TCP / All UDP 来源指向mediamtx-load-balancer安全组、mediamtx-originSSH 限管理员 IP 段Custom TCP8554和 All UDP 来源指向mediamtx-read-replicas安全组即只允许读副本从 origin 拉流另加发布者的 IP 段的 Custom TCP8554与 All UDP 规则供发布者推流。这个安全组划分直接体现了架构边界观众流量只到读副本副本流量到 origin发布者流量直接到 origin。在 origin 的 EC2 实例上通过 User data 安装 Docker 并以--network host运行bluenviron/mediamtx:1为读副本创建 Launch template其 User data 写入与上文相同的mediamtx.yml其中dns-of-origin替换为 origin 实例的私有 DNS同样以 host 网络运行。为每个协议/端口组合各建一个 Target grouptarget type 选 Instancesmediamtx-read-replicas-8554TCP8554RTSP健康检查 TCPmediamtx-read-replicas-1935TCP1935RTMP健康检查 TCPmediamtx-read-replicas-8890UDP8890SRT健康检查协议 TCP高级设置中把健康检查端口覆盖为8554mediamtx-read-replicas-8888HTTP8888HLS健康检查 HTTP成功码404mediamtx-read-replicas-8889HTTP8889WebRTC健康检查 HTTP成功码404。注意 HLS 与 WebRTC 的健康检查成功码设为404——这些端点在没有会话时返回 404这被视为健康状态。对8888和8889两个 Target group 打开 stickiness对应 L7 粘性会话要求。创建两个负载均衡器并共享mediamtx-load-balancer安全组Network Load BalancerTCP8554→ RTSP Target groupTCP1935→ RTMP Target groupUDP8890→ SRT Target groupApplication Load BalancerHTTP8888→ HLS Target groupHTTP8889→ WebRTC Target group。创建读副本的 Auto scaling group使用上面的 Launch template在 Load balancing 一节选择 Attach to an existing load balancer 并勾选全部 5 个 Target group在 Group size 的 Desired capacity 中设定实例数。验收方式同样来自文档用 Network Load Balancer 的 DNS 以 RTSP、RTMP、SRT 读流用 Application Load Balancer 的 DNS 以 HLS、WebRTC 读流。如果观众只使用单一协议例如仅 WebRTC可以只开放对应端口8889并只创建对应的负载均衡器Application load balancer其余步骤可省略。已知限制文档对读副本方案明确列出了三条限制规划时需要考虑突发流量峰值可以通过调整读副本数量来应对但调整不是即时的依赖自动扩缩容策略或人工操作期间可能出现短暂的性能下降读副本数量增加可能使副本与 origin 之间的带宽饱和形成新的瓶颈每台读副本都需要一台专用且可能昂贵的机器。针对 HLS 场景文档还提到另一种替代思路在 MediaMTX 的 HLS 服务器前面挂 CDN。但它的代价是只有 HLS 协议可用、Low-Latency HLS 播放列表无法缓存通常意味着要禁用 LL-HLS 变体、引入明显延迟、且 MediaMTX 标准鉴权机制不可用。如果观众需要低延迟或多种协议读副本仍是文档中的主路径。【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考