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的缺陷