pull的合并思路 about nginx-http-flv-module HOT 7 OPEN

在多子进程模式下，推流请求会被随机地分配给某个子进程，播放请求也会被随机地分配给某个子进程，但是如果为推流服务的子进程和为播放服务的子进程不是同一个子进程，那么播放会失败，所以才有了rtmp_auto_push这个指令，它让某个子进程接收到推流请求后，再把流relay给其他子进程，这样，不管播放请求被分配给哪个子进程，播放都能收到流。而对于播放pull，播放请求被分配给某个子进程，这个子进程根据配置，从上游去拉流，然后把流返回给播放请求，这没涉及到广播。即push流是一对多，而pull流是一对一，没必要合并。不知道这样解释能不能回答你的问题？或者我是否正确理解了你的问题？

from nginx-http-flv-module.

谢谢你的解释， 现在都是多核时代了， 甚至到了64cpu的，也就是说pull拉流回源多则32路回源，再加上分布式部署N台机器的话，无形中对中心机产生了很大的不必要的链接，当然nginx的机制跟srs不一样，srs的做法是单进程多线程所以一个source就可以解决问题。我记得nginx rtmp有个补丁， 这个补丁是将nginx worker每个都绑定不同的端口，端口之间进行合并压缩， 但这个方式我想似乎牺牲了
nginx多进程的优势。

from nginx-http-flv-module.

你说的是个问题，多进程的回源请求势必对上游服务器产生更大压力，其实更好的方法是用RTMP 302或者HTTP 302把请求按照一定规则分散到不同的上游服务器，这样不会对同一个上游服务器（或者集群）产生压力，但是很遗憾，支持RTMP 302的客户端非常少，服务器也需要修改代码，没一个好的团队来搞，不太现实。另外，仅仅据我个人测试，Nginx的多进程模型对于推流连接数的提升其实并不太理想，对于播放连接数的提升倒不错。

from nginx-http-flv-module.

我现在的想法是这样的， 这里有个补丁：
https://rarut.wordpress.com/2013/06/18/multi-worker-statistics-and-control-with-nginx-per-worker-listener-patch/
将worker绑定不同的端口，前端做对流进行hash转到固定的worker里面去， 这样的方式是我目前觉得算是一个比较合理的方案。

from nginx-http-flv-module.

空了我看看这个，nginx-http-flv-module对server配置块的组织结构跟nginx-rtmp-module相比改动很大，不知道能不能用

from nginx-http-flv-module.

如果设置为单核，pull会自动合并吗？

from nginx-http-flv-module.

谢谢你的解释， 现在都是多核时代了， 甚至到了64cpu的，也就是说pull拉流回源多则32路回源，再加上分布式部署N台机器的话，无形中对中心机产生了很大的不必要的链接，当然nginx的机制跟srs不一样，srs的做法是单进程多线程所以一个source就可以解决问题。我记得nginx rtmp有个补丁， 这个补丁是将nginx worker每个都绑定不同的端口，端口之间进行合并压缩， 但这个方式我想似乎牺牲了
nginx多进程的优势。

为了减少CDN内部的带宽，边缘节点的多进程和同节点的多台机器合并回源，其实很多CDN厂商都已经做过了
1）同一台机器上的多进程的话，你可以考虑流三元组hash 的方式，根据hash值对应一个进程，其他进程都可以去这个进程回源拉流，这样就只有一路回源了。
2）同节点多台机器的时候，也可以用hash的方式用一台机器去回源。

from nginx-http-flv-module.