nginx-rtmp-module的缺陷分析（二）

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。

其余文章：

nginx-rtmp-module的缺陷