django如何应对高并发(2023年最新解答)

发布网友 发布时间：2024-10-01 04:17

我来回答

共1个回答

热心网友 时间：2024-10-21 17:45

导读：很多朋友问到关于django如何应对高并发的相关问题，本文首席CTO笔记就来为大家做个详细解答，供大家参考，希望对大家有所帮助！一起来看看吧！

???Django本身自带了runserver，但是我们只是在测试的时候，会用到它，而在真正的生产部署一般都会使用uwsgi+nginx方式。

????因为我们的生产环境一般都会有很大的并发访问量，而django自带的runserver非常不稳定，最大连接数大约在几十个，过多的并发连接，导致服务崩溃，而且安全性上也不好。

????而nginx可以支持高并发连接，官方给出最大连接数在50000个左右，实际生产中，大约也在20000~40000个左右，内存消耗少，稳定性高，支持热部署（可以在不间断服务的情况下，进行版本升级）。

???相对比较而言，Django自带的runserver，只适合我们在测试的时候使用。

python的web框架很多

django(大而全，模板，orm都自带)

flask(pocoo出品，比属精品，自带jinja2模板，可以替换)

web.py(这个我没用过，作者自杀，白瞎了一个高手)

bottle(只有一个文件的框架，需要自己构建整个开发体系)

uliweb(中国人开发的，也很不错)

Tornado(异步框架，适合长连接，比如在线聊天之类的)

Python框架虽然说是百花齐放，但仍然有那么一家是最大的，它就是Django。Django为人所称道的地方主要有：

①完美的文档，Django的成功，我觉得很大一部分原因要归功于Django近乎完美的官方文档（包括Djangobook）。

②全套的解决方案，Django象Rails一样，提供全套的解决方案（full-stackframework+batteriesincluded），基本要什么有什么（比如：cache、session、feed、orm、geo、auth），而且全部Django自己造，开发网站应手的工具Django基本都给你做好了，因此开发效率是不用说的，出了问题也算好找，不在你的代码里就在Django的源码里。

③强大的URL路由配置，Django让你可以设计出非常优雅的URL，在Django里你基本可以跟丑陋的GET参数说拜拜。

④自助管理后台，admininterface是Django里比较吸引眼球的一项contrib，让你几乎不用写一行代码就拥有一个完整的后台管理界面。

做个比喻,如果说A是服务端,B是客户端,现在要在A家里吃火锅,虽然A说你人来就行,但是B心想总得带点东西过去,于是去了市场.

先到了蔬菜店,B想买点菠菜,但又怕A家里已经有了,于是给A打电话

B:"我带点菠菜过去吧?"

A:"好"

然后挂断.过一会儿到了水产区

B:"我带点虾过去吧?"

A:"不用"

...如此反复多了之后A突然发现自己确实少准备了一些东西,于是A给主动给B打了电话

A:"我忘准备蘸料了,你买点,然后先别挂掉"

...

A:"再买瓶酒"

...

这就是websocket了

django当让也提供对websocket的支持,虽然这似乎不是他更擅长的东西.我们可以通过channels实现websocket连接

诸如上述例子的场景都是合适的场景

举例来说的话比如聊天室,每个人发送的消息都要实时显示在别人的屏幕上.

比如说数据监控,波动状态也要实时的呈现在屏幕上,而不是依赖于使用者自己刷新.

需要安装channels,asgi_redis,asgiref,channels_redis.后三个未必都需要装,记不太清了,总之安装过程都在channels的使用文档上.

INSTALL_APPS中需要加上"channels",需要注意的是因为这是一个list,是有先后顺序的,最好把它加在第一个.

这里我们的channel通过redis实现,要在settings.py中配置

这里还有点小坑,官方文档里的hosts不是这种格式,是"uri"这种模式,但是如果你在设置redis密码时机智的设置了特殊符号('#$%'这种),你就会发现redis的uri直接就用不了了,期间尝试各种方法,转义什么的也试了都不行,然后去github上开了个issue,结果作者说我们是通过aioredis连接的,你去找他们的文档吧....

然后就找到了这种方式.

常规的WSGI不支持websocket,所以还需要配置ASGI

ASGI_APPLICATION='project.routing.application'

同wsgi的配置一样,这是指向project文件夹下routing.py文件的application

这里建议大家跟这官方教程的Tutorial走一遍.有个比较悲剧的地方就是网上可以搜到许多channels使用指南,大多都是搭个简易聊天室什么的,然而你用起来可能发现存在各种报错,因为channels升了2.0之后更改了一些方法,而那些教程里基本全都是1.x的版本.

简单说下,首先startapp叫chat,假如这里我们没有进行前后端分离,里面有templates,两个html:index和room分别对应首页和某一个聊天室

新建consumers.py来写websocket方法

如上,connect和disconnect含义分别如函数名.因为是聊天室,所以同一个聊天室内的人应该消息共享,用room_group_name来区分所在的频道.

receive和chat_message是对消息的处理.当一个用户发送消息时,前端把消息通过websocket发送过来,receive收到消息提取关键内容,通过chat_message发送给组内的所有连接.这时保持连接的所有组内人员都会收到这条消息推送,前端收到推送再显示在屏幕上.

定义websocket的地址

类似于django的url(consumers.py就类似于views.py),同级新建routing.py

统一用ws/来区分websocket的连接

剩下常规的页面配置和django一样

views.py:

urls.py:

注意:如果网站是http,连接使用ws,如果是https要修改成wss

剩下的自己找资料吧,笔者对前端了解的不多

本地的话runserver就好了,但是在线上还是得更改启动方式应对高并发.

传统的uwsgi不支持websocket.

gunicorn好像可以同时支持websocket,但是性能不太ok

这里我们用daphne

这里需要额外开个服务,专门负责处理websocket.

ingress中要配置路由跳转

django自带的那个是效率相当低下的，它没有采用epoll/kqueue。

具体支持多少人在线，这个很难说。

测了一下，对于我的电脑，初始django工程的根的并发能力大概是294。

相比而言，tornado是高性能的server，用它文档的web的范例，并发能力大概是1324。

对nginx上的一个只包含“helloworld!"的静态文件的访问，并发能力大概是2942