一种比较别扭的 python 多进程 HTTP 服务实现方式，大家觉得如何。？

[2225377fjs]

对于 Python 而言，在线上部署 HTTP 服务的时候，一般都是采用多进程的方式来做的，毕竟没有 Java 的并行多线程，所以常规的方式是前面通过一个 Nginx 来做反向代理，后端启动多个 Python 进程，监听多个端口。（当然还有一种方式是通过子进程共享 listen 文件描述符来实现，但是这种方式对于 Python 而言会有一些不好的问题）

在 linux 下还有另外一种实现方式，因为有 sendmsg 和 recvmsg 两个方法： 通过启动一个进程，专门来做 tcp 的监听，然后启动多个进程来做 worker ，通过 Unix 域 socket 与监听进程建立连接，监听进程将接收到的文件描述符通过 sendmsg 方法发送给 worker 进程，然后 worker 进程将文件描述符放入自己的 IOLoop ，当做一个正常的 Tcp 连接处理就好了。。。

这种方式的优点： 对于 http 服务器而言，少了一个反向代理的过程，本身 nginx 那部分 http 解析的过程可以省掉一些 CPU ，而且对于 python 进程而言部署相对方便一些，不用去设置多个端口。 缺点： 只支持物理单服务器，不可能扩展到多个物理服务器，不支持 Windows ， python 本身 socket 不带有 sendmsg API ，需要些 C 扩展。

其实这个功能最开始是为了做 Tcp 服务器搞的，在架设 gate 系统的时候，只监听一个端口，然后可以方便的扩展出一些负载均衡的功能。

http://blog.csdn.net/fjslovejhl/article/details/50481961

[micyng]

@2225377fjs 你现在说的这些东西其实 Nginx 已经成熟地支持了
另外子进程共享的方式，操作系统会处理好 accept 分发的事
还有如果特别针对多进程环境下 TCP 长连接的情况，大可不必担心，因为这种模型不会用于推送的场景，而是处理较大流数据的上传下载业务，用一段时间就关了，跟一个 http 请求其实没什么两样
换做推送场景的话，也不会用多进程模型了，而是得考虑分布式节点了

[micyng]

@2225377fjs 你现在说的这些东西其实 Nginx 已经成熟地支持了
另外子进程共享的方式，操作系统会处理好 accept 分发的事
还有如果特别针对多进程环境下 TCP 长连接的情况，大可不必担心，因为这种模型不会用于推送的场景，而是处理较大流数据的上传下载业务，用一段时间就关了，跟一个 http 请求其实没什么两样
换做推送场景的话，也不会用多进程模型了，而是得考虑分布式节点了

[micyng]

我的 1%被识别成安卓猴了😈

[wuyadong]

uwsgi

[clino]

@2225377fjs uwsgi 也支持 gevent 和 virtualenv 的
可以自身作为 http server,也可以用自定义的 socket 协议和 nginx 交互,当然自身作为 http server 再被 nginx 反代也行

[tomZhao]

一般而言，会使用 gunicorn/uwsgi 做 server 来处理也就是你说的第二种。老实说，我比较不喜欢这种方式，
使用 supervisord 来启动多进程，监听多个端口， nginx 反向代理，则是第一种方式，也可以。我比较喜欢。可以做一些小的优化，比如 cpu 绑定之类的。