大家好，欢迎来到IT知识分享网。
gunicorn是一个
python Wsgi http server，只支持在Unix系统上运行，来源于Ruby的unicorn项目。Gunicorn使用
prefork master-worker模型（在gunicorn中，master被称为arbiter），能够与各种wsgi web框架协作。gunicorn的文档是比较完善的， 这里也有部分中文翻译，不过还是建议直接读英文文档。笔者并没有在项目中真正使用过gunicorn，阅读其源码只要是为了了解其master worker模型，如有纰漏，还请多多指教。
python Wsgi http server，只支持在Unix系统上运行，来源于Ruby的unicorn项目。Gunicorn使用
prefork master-worker模型（在gunicorn中，master被称为arbiter），能够与各种wsgi web框架协作。gunicorn的文档是比较完善的， 这里也有部分中文翻译，不过还是建议直接读英文文档。笔者并没有在项目中真正使用过gunicorn，阅读其源码只要是为了了解其master worker模型，如有纰漏，还请多多指教。
gunicorn的安装非常简单，
pip install guncorn 即可。后续如果用到异步的worker模型，还需要安装对应的模块（如gevent）
pip install guncorn 即可。后续如果用到异步的worker模型，还需要安装对应的模块（如gevent）
在装好gunicorn之后, 我们来看看gunicorn的hello world。代码来自官网，将下面的代码放到gunicorn_app.py中：
1 def app(environ, start_response): 2 data = b"Hello, World!\n" 3 start_response("200 OK", [ 4 ("Content-Type", "text/plain"), 5 ("Content-Length", str(len(data))) 6 ]) 7 8 return iter([data])
可以看到app是非常标准的wsgi应用，然后我们启动gunicorn：gunicorn -w 2 gunicorn_app:app。 输出如下：
上图展示了两个很重要的信息：
第一：启动了两个worker，这是通过”-w 2″指定（默认为1）
第二：worker的工作模型是sync（默认），后面会详细介绍worker模型
然后在另外一个terminal运行：
ps -ef | grep python
ps -ef | grep python
可以看出 worker进程（pid：19469， 19470）是master进程（pid：19464）的子进程。
新起一个terminal，用curl测试：
curl 127.0.0.1:8000
curl 127.0.0.1:8000
在该terminal输出“Hello, World!”
前面提到，官方gunicorn只能在Unix上运行（貌似也有非官网的补丁，使其能在windows上运行，未求证），主要是因为源码中使用了
fcntl，os.fork等只在unix上存在的模块和接口。pre-fork就是指gunicorn启动的时候，在主进程中会预先fork出指定数量(-w）的worker进程。这里先简介Master Worker的工作流程，后文再对代码做详细介绍。
fcntl，os.fork等只在unix上存在的模块和接口。pre-fork就是指gunicorn启动的时候，在主进程中会预先fork出指定数量(-w）的worker进程。这里先简介Master Worker的工作流程，后文再对代码做详细介绍。
启动gunicorn，首先初始化gunicorn.app.base.Application（或者基类，比如上面从命令行启动时，是wsgiApplication），初始化中最重要的是读取配置，支持文件或者命令行。然后调用Application.run()，该方法代码如下：
def run(self): try: Arbiter(self).run() except RuntimeError as e: print("\nError: %s\n" % e, file=sys.stderr) sys.stderr.flush() sys.exit(1)
调用Arbiter(self).run()之后，主进程（master）的所有逻辑都运行在Arbiter类里面。
Arbiter首先读取配置项， 如worker数量，worker工作模式，监听的地址等；然后初始化信号处理函数，然后建立socket，
不过并不listen；接下来fork出所有的worker进程；最后进入循环：处理信号队列中的信号，杀掉并重启失去响应的子进程，如果没事儿干，就“sleep”一会儿。
不过并不listen；接下来fork出所有的worker进程；最后进入循环：处理信号队列中的信号，杀掉并重启失去响应的子进程，如果没事儿干，就“sleep”一会儿。
worker进程就更加简单一下，首先是读取配置，初始化信号处理函数，然后进入循环：处理监听端口上的请求（也就是会调用到wsgi app的地方），然后向master报告自己还活着。另外，worker中是在信号发生的时候直接处理信号，而不是像master一样放入信号队列。
可以稍微改动一下app代码，以便在客户端请求的时候，服务器端能打印调用栈，下面是在我的机器上的输出，后面将会对Arbiter和worker进行介绍。
- 0: FUNC:app(…) /home/xxx/gunicorn_app.py::16
- 1: FUNC:handle_request(…) /usr/local/lib/python2.7/dist-packages/gunicorn/workers/sync.py::176
- 2: FUNC:handle(…) /usr/local/lib/python2.7/dist-packages/gunicorn/workers/sync.py::135
- 3: FUNC:accept(…) /usr/local/lib/python2.7/dist-packages/gunicorn/workers/sync.py::30
- 4: FUNC:run_for_one(…) /usr/local/lib/python2.7/dist-packages/gunicorn/workers/sync.py::68
- 5: FUNC:run(…) /usr/local/lib/python2.7/dist-packages/gunicorn/workers/sync.py::124
- 6: FUNC:init_process(…) /usr/local/lib/python2.7/dist-packages/gunicorn/workers/base.py::132
- 7: FUNC:spawn_worker(…) /usr/local/lib/python2.7/dist-packages/gunicorn/arbiter.py::557
- 8: FUNC:spawn_workers(…) /usr/local/lib/python2.7/dist-packages/gunicorn/arbiter.py::590
- 9: FUNC:manage_workers(…) /usr/local/lib/python2.7/dist-packages/gunicorn/arbiter.py::524
- 10: FUNC:run(…) /usr/local/lib/python2.7/dist-packages/gunicorn/arbiter.py::189
- 11: FUNC:run(…) /usr/local/lib/python2.7/dist-packages/gunicorn/app/base.py::72
- 12: FUNC:run(…) /usr/local/lib/python2.7/dist-packages/gunicorn/app/base.py::192
- 13: FUNC:run(…) /usr/local/lib/python2.7/dist-packages/gunicorn/app/wsgiapp.py::74
- 14: FUNC:<module>(…) /usr/local/bin/gunicorn::11
references
http://gunicorn.org/
http://gunicorn.readthedocs.io/en/latest/
http://www.wzxue.com/gunicorn%E7%9A%84%E4%BB%A3%E7%A0%81%E7%BB%93%E6%9E%84%E4%B8%8E%E5%88%86%E6%9E%90/
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://yundeesoft.com/30830.html
