django怎么处理高并发

django 的并发能力真的是令人担忧，这里就使用 nginx + uwsgi 提供高并发

nginx 的并发能力超高，单台并发能力过万（这个也不是绝对），在纯静态的 web 服务中更是突出其优越的地方，由于其底层使用 epoll 异步IO模型进行处理，使其深受欢迎

做过运维的应该都知道，php 需要使用 nginx + fastcgi 提供高并发，java 需要使用 nginx + tomcat 提供 web 服务

python学习网，大量的免费Django入门教程，欢迎在线学习！

如何再次增加并发量

采用nginx做负载

去掉自增主键

原因很简单,因为自增主键的存在写库存在抢锁, 可以利用全局id生成器提前生成id直接写入数据库

换成异步任务去写库

如果数据只是存在mysql中做备份，建议使用异步的方式写入库，先把数据写到缓存下发给用户，之后在利用后台异步任务一点点的写入，例如聊天系统可以这样干

换成更高效的框架或者语言

可以试试tornado, 如果tornado依然无法满足，可以尝试使用golango，毕竟golang是以高并发著称, 而且是编译语言，而且基于它的web框架也很容易上手，性能很可观，例如Iris。

django

毫无疑问，用原生django的server做处理的表现是最烂的，在10000次请求的情况下brokenpipe的几率极高，只有1400次请求被处理，成功率只有14%。

django + nginx

这次搭上了nginx做反向代理，也使的脆弱的django服务器的情况有所缓解，但成功率仍然不高（10000次请求中有3684个请求被处理）。

uwsgi + nginx

uwsgi是性能极高的一个由C编写的服务器，它使用uwsgi协议，这次让它配合nginx处理django的request，参数为4进程+2线程，性能立即直线上升，处理请求的成功率也基本在90%左右，不过我在测试时遇到了一个坑，就是uwsgi在处理请求的时候发送了队列溢出的问题，因为当前测试设置的并发数为每秒1000次并发，而uwsgi的处理队列容量默认为100，导致处理请求的时间加长，而这个问题则可以通过修改somaxcon的大小解决，总的来说，使用uwsgi+nginx是一个理想的选择。

gunicorn + nginx

gunicorn跟uwsgi类似，也是一个高性能的http服务器，它由ruby的unicorn项目移植，是由python编写的，它的配置简单，而且可以灵活地搭配其他网络库，部署十分方便，在测试数据中可以看到，用这种配置运行django能在短时间内就能处理大量的并发请求，成功率在90%左右。

gunicorn + nginx + gevent

前面说的几种环境，看似不错，但我们需要追求完美！由于gunicorn是同步（sync）单线程模型的，有的时候它不免会发生一些阻塞问题，这时候我们为gunicorn加上-k gevent参数来用gevent做处理接口，这就比较靠谱地处理了阻塞问题，从数据中可以看到，gunicorn + nginx + gevent的模式不仅拥有100%的处理成功率，而且时间也在很短之内完成，是5组测试数据当中的性能最好的。

多套方案来提高 python web 框架的并发处理能力

Python 常见部署方法有 ：

fcgi ：用 spawn-fcgi 或者框架自带的工具对各个 project 分别生成监听进程，然后和 http 服务互动

wsgi ：利用 http 服务的 mod_wsgi 模块来跑各个 project(Web 应用程序或框架简单而通用的 Web 服务器 之间的接口)。

uWSGI 是一款像 php-cgi 一样监听同一端口，进行统一管理和负载平衡的工具，uWSGI，既不用 wsgi 协议也不用 fcgi 协议，而是自创了一个 uwsgi 的协议，据说该协议大约是 fcgi 协议的 10 倍那么快。

其实 WSGI 是分成 server 和 framework (即 application) 两部分 (当然还有 middleware)。

严格说 WSGI 只是一个协议, 规范 server 和 framework 之间连接的接口。

WSGI server 把服务器功能以 WSGI 接口暴露出来。比如 mod_wsgi 是一种 server, 把 apache 的功能以 WSGI 接口的形式提供出来。

WSGI framework 就是我们经常提到的 Django 这种框架。不过需要注意的是, 很少有单纯的 WSGI framework , 基于 WSGI 的框架往往都自带 WSGI server。比如 Django、CherryPy 都自带 WSGI server 主要是测试用途, 发布时则使用生产环境的 WSGI server。而有些 WSGI 下的框架比如 pylons、bfg 等, 自己不实现 WSGI server。使用 paste 作为 WSGI server。

Paste 是流行的 WSGI server, 带有很多中间件。还有 flup 也是一个提供中间件的库。

搞清除 WSGI server 和 application, 中间件自然就清楚了。除了 session、cache 之类的应用, 前段时间看到一个 bfg 下的中间件专门用于给网站换肤的 (skin) 。中间件可以想到的用法还很多。

这里再补充一下, 像 django 这样的框架如何以 fastcgi 的方式跑在 apache 上的。这要用到 flup.fcgi 或者 fastcgi.py (eurasia 中也设计了一个 fastcgi.py 的实现) 这些工具, 它们就是把 fastcgi 协议转换成 WSGI 接口 (把 fastcgi 变成一个 WSGI server) 供框架接入。整个架构是这样的: django -> fcgi2wsgiserver -> mod_fcgi -> apache 。

虽然我不是 WSGI 的粉丝, 但是不可否认 WSGI 对 python web 的意义重大。有意自己设计 web 框架, 又不想做 socket 层和 http 报文解析的同学, 可以从 WSGI 开始设计自己的框架。在 python 圈子里有个共识, 自己随手搞个 web 框架跟喝口水一样自然, 非常方便。或许每个 python 玩家都会经历一个倒腾框架的。

uWSGI 的主要特点如下：

超快的性能。

低内存占用（实测为 apache2 的 mod_wsgi 的一半左右）。

多app管理。

详尽的日志功能（可以用来分析 app 性能和瓶颈）。

高度可定制（内存大小限制，服务一定次数后重启等）。