nginx直播带宽(nginx直播推流)

nginx直播推流

Python Web 程序的部署方案

综合而言, 高性能的Python web站点部署方式首推 nginx + uwsgi

apache + mod_wsgi 是简单稳定但性能一般的方式

API服务器 可以直接使用tornado或者gevent

mod_python

非常原始的cgi模式部署python已经没有什么好介绍了。对于不太追求性能的管理系统和网站来说，使用 Apache 部署是一个不错的选择。较早的时候，使用 mode_python 部署python的web应用十分流行,在Django 0.96 的时候官方文档甚至推荐这种方式。

它将Python解释器嵌入到Apache server,以提供一个访问Apache server内部的接口。mod_python 在现在看来性能是不佳的，每一个http请求 mod_python 都会由一个进程初始化python解释器、载入代码、执行、然后销毁进程。

mod_wsgi

如果非要用Apache来部署python应用，mod_wsgi是一个更好的选择。WSGI 全称是 Web Server Gateway Interface ,由 PEP-333 定义。 基本上所有的python web框架都实现了wsgi接口，用mod_wsgi 能部署任何实现了wsgi的框架。实际上，不需要任何框架也可以用mod_wsgi 部署python程序。使用mod_wsgi的daemon模式，python程序会常驻内存，不会有很大的初始化和销毁进程方面的开销，所以性能是好于mod_python的。综合来说，使用Apache部署python web程序，推荐使用mod_wsgi的daemon模式。

Fastcgi

先说观点：不建议用fastcgi的方式部署Python web。

前几年由于lighttpd风头正劲和豆瓣的成功案例，fastcgi是一种很流行的部署方式。fastcgi与具体语言无关，也与web服务器无关。是一种通用的部署方式。fastcgi是对于cgi的增强，CGI程序运行在独立的进程中，并对每个Web请求建立一个进程。面对大量请求，进程的大量建立和消亡使操作系统性能大大下降。

与为每个请求创建一个新的进程不同，FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI服务器管理，而不是web服务器。 当进来一个请求时，web服务器把环境变量和这个页面请求通过一个socket比如FastCGI进程与web服务器都位于本地）或者一个TCP connection（FastCGI进程在远端的server farm）传递给FastCGI进程。

主流的web服务器，Apache,lighttpd,nginx 都支持fastcgi，在几年前，lighttpd的mod_fcgi模块性能强劲，lighttpd+fastcgi十分流行。无论是python,ruby还是php，都有大量的站点使用这种方式部署。由于nginx的崛起，现在很少有人使用lighttpd了。

fastcgi 并不是专门为python设计，并不是所有的python框架天然的支持fastcgi，通常需要flup这样的容器来配适。flup由python编写，和专门的c实现的wsgi容器比起来性能显得相当不堪。fastcgi的稳定性对于新兴的wsgi容器来说也有差距。无论从哪个方面来看，部署python web程序，fastcgi 都已经是过去式。

uwsgi

前几年nginx还未内置uwsgi模块的时候，部署uwsgi还是一件挺麻烦的事情。随着能够在nginx中直接使用uwsgi模块，uwsgi已经是最可靠，最方便的高性能python web程序的部署方式了。

在1U的四核XEON服务器上，一个简单的wsgi handler甚至能用AB压到8000以上的qps,这已经是完爆tornado,接近gevent的性能了。 同时，uwsgi的稳定性极好。之前我们有个每天500w-1000w动态请求的站点使用uwsgi部署非常稳定，在一个渣HP 1U 服务器上，基本不用管它。

上面提到的部署方式都是相对于web网站的方式，在移动互联网的时代，我们需要的是高性能的API服务，上面这些都是过时的东西。

tornado

tornado 号称高性能，如果拿他写网站，其实一般般，只不过跟uwsgi加一些简单框架差不多而已。它真正的作用，是用来写API服务器和长连接的服务器。

由于tornado能够直接处理http请求，很多人直接拿他来裸奔直接提供服务。这种方式是不可取的，单线程的tornado只能利用cpu的一个核心，并且一旦阻塞直接就废了。通常情况下，由supervisor启动多个tornado进程，通过nginx进行反向代理负载均衡。nginx 1.14 以后的版本反向代理支持长连接，配合tornado的comet效果很好。

tornado还有一些比较奇葩的用法，比如用来做wsgi容器之类的。

gevent

gevent是一个神器，能做的事情很多。在web方面，处理http请求，用起来其实跟tornado差不多，但是要简陋很多，cookie之类的都没有。用gevent写的一些API服务，部署方式还是类似tornado，用supervisor管理多个守护进程，通过nginx做负载均衡。 同样的它的奇葩用法也和tornado一样，可以当wsgi容器用。

nginx+obs 推流服务器

直播双机位指的是在直播或者录制视频的时候，使用两台摄像机分别拍摄主播或者讲述者，然后将两台摄像机的画面混合在一起，生成一个视觉效果更加丰富、生动的视频。实现直播双机位的搭建，需要以下步骤：

1. 准备两台相同规格的高清摄像机，以及必要的专业器材，如三脚架、视频转接线、麦克风等。

2. 将两台摄像机分别放置在合适的位置上，尽量保证两个角度的视野互相补充，避免画面的重叠和冲突。同时要进行摄像机的白平衡、曝光等参数的调整，以保证摄影效果的一致性。

3. 连接两台摄像机到一个视频混合器上，这个视频混合器可以将两个摄像机的画面混合在一起，实现直播双机位的效果。同时要确保混合器具备音频的输入和输出，方便与麦克风、音响、录音机等设备进行连通。

4. 接下来需要连接整个拍摄系统的电源供应和信号输入输出，包括摄像机和混合器的电源和信号输入，以及音响和录音设备的音频输入输出。同时需要做好防静电、防水、防摔等安全措施，确保设备的顺利运作和使用寿命。

通过以上步骤的操作，就可以成功搭建一个直播双机位的设备了。在使用过程中，还需要注意操作细节，比如摄像机的调焦、曝光、白平衡，录音设备的音量、清晰度等。希望这些内容可以对您有所帮助。

nginx直播推流并发

互联网信息服务（英语：InternetInformationServices,简称IIS），是由微软公司提供的基于运行MicrosoftWindows的互联网基本服务。

IIS可设置的属性包括：虚拟目录及访问权限、默认文件名称、以及是否允许浏览目录。

Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率。

nginx是用另外一种方式来处理请求的。当请求处理达到一个峰值的时候，会要求这些请求等待，当有空间的时候再放进来。这就是基于事件为导向的处理方式。

因为事件消耗的资源，要比进程消耗的资源小的多的多，所以nginx，在同等性能的条件下能够处理4倍于Apache服务器的请求。

nginx flv 直播

要把录制好的视频直接用于直播，可以采取以下步骤：

1. 使用一个支持直播的流媒体服务器，如NGINX-RTMP或Wowza Streaming Engine等。将录制好的视频文件上传到这个服务器上。可以使用FTP或SFTP等协议来将视频文件传输到服务器上。

2. 在直播流转码服务器上，使用专业的流媒体转码软件对上传的视频文件进行转码，以确保该视频文件与您要使用的直播平台和播放器兼容。比如常见的直播流转码软件有FFmpeg等， FFmpeg 支持 AVI、WMV、MOV、FLV、MP4 等格式的文件，而且还能够通过 HTTP、RTMP、RTSP、HLS 等协议进行转码。

3. 使用直播流媒体分发系统推流到直播平台，即可将录制好的视频直接用于直播。在推流前，需要获取直播平台提供的推流地址和流名称信息。

需要说明的是，使用录制好的视频直播时，可以采用“录播”的方式，即预先录制好视频，然后用流媒体服务器进行转码、压缩等处理，实现直播转播。这种方式可以降低直播过程中的网络带宽和 CPU 占用等压力，并且可以提前制作一定数量的视频，以满足长期直播需求。

nginx obs推流

出现这个问题，八成是上行网络和服务器链接问题导致。

也就是常说的重连机制，连不上嘛，只能反复重连了。

如果有服务端的stat监控（比如nginx），可以打开服务器状态看看，是不是有publish链接上去。

如果是第三方云服务，应该有相应的后台可以看得到。

nginx直播延迟

　由于网站流量过大 日IP过百万 导致CPU疯狂的上涨直接到百分之100的运行率，导致服务器崩溃，死机，而经过几天的研究得出了一个结果，那就是连接堵塞导致死循环死机，每次死机后只要重启之后又可以大概2-3小时后再次堵塞死机，经过程序员的分析，可能是流量超过了延迟导致死机的。