【Gunicorn】源码阅读笔记

源码阅读 gunicorn

源码分析的一个项目，之前基本都是浏览各种源码，对其中的细节看的少，没有总结，也没有更高层次的归纳，所以这次认真的来分析一个Py项目的源码。 gunicorn是python的一个http服务器，来看看怎样设计和实现一个HTTP服务器。

目标

没有任何目的的研究可能也收获不了什么。

• Python prefork模式的设计和实现
• wsgi 服务器的实现, 从socket到wsgi的environ 还有response的封装
• 不同异步方式的抽象和适配器的实现
• Python做系统编程的一些知识

阅读时候在源码上加了一些注释，放到github gunicorn-souce-reading

参考资料：

• Desgin
• understanding-gunicorns
• Gunicorn 代码阅读 写的比较详细，对理解很有帮助, 特别是调试的方法，推荐读一读
• 源码阅读 这是个项目 分析的比较详细

设计思想

• 基于 pre-fork 模型，有一个master进行来管理多个worker进程来工作。 请求的接收和返回都是worker来完成的。
• 提供了多中worker类型：同步worker，基于Greenlets的异步worker，Tornado worker，还有py3中的AsyncIO worker。

我这里是 git clone 出来源码之后，直接使用软连接替换 virtualenv 中的gunicorn源码来实现调试的。

源码结构

这里的版本是19.45。 源码包中包含了 docs(文档），examples（案例），tests（测试）以及 gunicorn（py源码）还有一些安装脚本，说明信息等。

py源码的目录结构。

gunicorn
├── __init__.py
├── _compat.py
├── app
│   ├── __init__.py
│   ├── base.py
│   ├── django_wsgi.py
│   ├── djangoapp.py
│   ├── pasterapp.py
│   └── wsgiapp.py
├── arbiter.py
├── argparse_compat.py
├── config.py
├── debug.py
├── errors.py
├── glogging.py
├── http
│   ├── __init__.py
│   ├── _sendfile.py
│   ├── body.py
│   ├── errors.py
│   ├── message.py
│   ├── parser.py
│   ├── unreader.py
│   └── wsgi.py
├── instrument
│   ├── __init__.py
│   └── statsd.py
├── management
│   ├── __init__.py
│   └── commands
│       ├── __init__.py
│       └── run_gunicorn.py
├── pidfile.py
├── reloader.py
├── selectors.py
├── six.py
├── sock.py
├── util.py
└── workers
    ├── __init__.py
    ├── _gaiohttp.py
    ├── async.py
    ├── base.py
    ├── gaiohttp.py
    ├── geventlet.py
    ├── ggevent.py
    ├── gthread.py
    ├── gtornado.py
    ├── sync.py
    └── workertmp.py

• app 目录 django适配和wsgi app相关的代码 其中wsgiapp.py 是程序的总入口
• http 目录 http协议处理的相关代码
• instrument目录 是statsD，gunicorn运行状态的相关代码
• management目录 是shell gunicorn 命令处理相关代码
• workers目录 中是不同类型worker的实现
• arbiter.py 核心文件 进程的控制逻辑基本都在这里
• config.py 配置的解析和生成 cfg对象
• debug.py 调试相关的操作和设置
• sock.py 对标准socket库的一层封装
• util.py 公共的工具方法

Master-workers

这模式从早期的版本就有了，github上最早能看到的tag是0.2, 那个版本比较容易理解，worker是同步模式，功能相对少一些。7.0版本开始添加 async的支持，worker可以有多种选择。

核心是arbiter.py文件，通过信号来控制进程的行为，需要一些操作系统和系统编程的知识才比较好理解。

涉及到的信号

• HUP 1 重新加载配置文件
• QUIT 3 退出信号
• INT 2 Ctrl+C 发出的终止信号
• TERM 15 清除状态并退出
• TTIN 当后台作业要从用户终端读数据时, 该作业中的所有进程会收到SIGTTIN信号. 缺省时这些进程会停止执行 增加一个work
• TTOU 类似于SIGTTIN, 但在写终端(或修改终端模式)时收到 减少一个work
• USR1 用户使用 杀死所有works
• USR2 用户使用 重新加载
• WINCH 窗口改变信号

疑惑

通读了这段代码之后，pipe 管道和 signal 信号相互怎么作用的一直没明白。 为什么要用 pipe的读写来唤醒和休眠进程？ 信号发出之后怎样添加到signal queue中的？

想法： 然后我就把所有的wakeup和sleep的代码都注释掉，发现程序运行的好好的，就是说整个master的loop频率非常快。 这个时候把 sleep开启（wakeup仍然注释），调整的5秒，再次测试的时候发现loop变成5s了，使用Ctrl+c来停止进程，有时候甚至是无法响应的，有时候可以接受到信号。 再接着把wakeup打开，sleep调整到5s， Ctrl+c就能即时响应了，loop时间还是5s左右。 所以猜测这里用pipe读写+select 来减少master loop的资源消耗，并仍能即使响应系统信号。

arbiter.py 执行流程

1. __ini__() 初始化各种参数，包括设置app，app的配置
2. run() 开始进程
3. start() 写入pid
4. init_signals() 初始化所有信号的handler，重新创建pipe
5. create_sockets 创建监听的socket
6. worker_class 是否要配置不同的worker
7. 第一次初始化所有子进程
8. 进入master的循环
   
   • 检查worker是否一致
   • 检查是否有新的信号 （如果有信号到来，就根据不同信号给不同的handler来处理）

不同worker

worker进程才是主要干活的工人，之前就说gunicorn提供了多个类型的worker，来看看他们是怎么实现的？代码在workers目录下。 worker的主要功能：
1. 对信号的处理
2. 接受socket内容，解析成http，遵循wsgi调用返回http响应

• base.py

这里是其他worker的父类，定义了接口和公共方法（进程处理相关的居多) ,各种worker在会具体的实现这些接口。

• sync worker

默认的是一种同步的worker，也是最简单和最早的类型。

大概工作的流程：

1. 子进程被fork出来之后，会调用 worker 对象的 init_process()方法 （base.py中定义和实现）
2. 根据配置检查是否需要重新载入配置，如果有配置会reload配置
3. 检查配置中是否有env变量需要设置，如果有配置env变量
4. 设置子进程的用户组和用户
5. 重新设置随机种子 util.seed()
6. 新建一个pipe 并初始化
7. 处理socket文件描述符 util.close_on_exec() 防止文件描述符继承
8. 初始化信号的handler self.init_signals()
9. 执行 post_worker_init 加载 server hook
10. 加载wsgi模块 self.load_wsgi()
11. 调用run() (sync.py）
    
    • 设置socket为nonblocking
    • 根据socket个数进行单个socket（run_for_one）或者多个socket的监听 (run_for_multiple)
    • 后面的逻辑就是不听的 loop，检查自己进程和父进程都alive的情况下，不断接受和处理请求 self.accept(), 使用的是select 来处理事件循环。

怎样从conn和handle 变成 reqeust和response的呢？

• gevent worker

如果想使用基于gevent的worker使用 -k 参数 gunicorn test:app -k gevent

继承关系 base.Worker -> AsyncWorker -> GeventWorker

• gthread worker

多线程的worker，依赖futures模块，使用线程来处理每个连接，用到了线程池。