nginx-rtmp-module使用指令push和pull来relay媒体流数据，以便分布式部署服务。
当nginx-rtmp-module作为边缘服务器（一般不会向边缘服务器推流）时，使用pull从源服务器获取媒体流数据，俗称“回源”。先看原理图：
注意：上图是单进程模式的pull回源图。可以看出，多个连接请求同一个媒体流（RTMP的URL格式为：rtmp://host[:port]/app/stream，stream用来表示流名称）时，只会有一个回源连接去请求上游服务器。
众所周知，Nginx绝大多数情况下使用的都是多进程模式，那么实际的pull回源图是下面的样子：
那么问题来了：由于不同的worker进程上存在着相同的流媒体请求，每个worker进程都会向上游服务器发起一个pull中继请求，这会增加带宽消耗，也会增加上游服务器的压力。
那么要如何才能解决这个问题呢？pull同名回源合并。什么意思呢？就是对于上游服务器来说，同名pull回源请求应该只有一个，而不是因为下游服务器有多个worker进程导致有多个。实现的方法跟nginx-rtmp-module的缺陷分析中的方法类似，最开始向上游服务器发起pull的worker进程记录流媒体信息与worker进程的映射关系，后续的pull请求先查找这个映射关系，如果查到了，就直接去已经pull的进程那里请求媒体流，否则它再向上游服务器发起pull请求：
这么做以后，会将网络带宽消耗降低到原来的方案的1/N（N为Nginx的worker进程数，假设每个worker进程至少能接受一个同名媒体流连接），上游服务器的压力也降低到原来的方案的1/N。有人可能会问，你这不是把给上游服务器的压力放到本地服务器上了么？是的，但是本地服务器的worker进程间传输数据比跨网络传输数据更可靠（使用unix domain socket实现），耗费的时间也会更少。
有人可能会问，push能这么做么？答案是不需要，因为对于一个服务器来说，同名play可以有多个，但是同名push只能有一个。好了，本次nginx-rtmp-modue的缺陷就介绍到这里，后续我会写文章介绍nginx-rtmp-module其他的一些缺陷。
欢迎关注我在nginx-rtmp-module的基础上开发的项目：nginx-http-flv-module。
其他文章：