文章目录

Django缓存安装Redis设置Django缓存全站缓存视图缓存模板缓存底层缓存缓存

API

Celery配置Celery生产异步任务生产定时任务任务结果Django集成CeleryDjango-任务交给CeleryCelery

绑定参数Celery

面向切面编程是对业务逻辑的各个部分进行隔离从而使得业务逻辑各部分之间的耦合度降低提高程序的可重用性同时提高了开发的效率。

可以实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。

面向切面编程就是将交叉业务逻辑封装成切面利用AOP的功能将切面植入到主业务逻辑中。

所谓交叉业务逻辑是指通用的与主业务逻辑无关的代码如安全检查事务日志等。

若不使用AOP则会出现代码纠缠即交叉业务逻辑与主业务逻辑混合在一起。

这样会使业务逻辑变得混杂不清。

Django的中间件就是应用AOP技术来实现的它是django请求/响应处理的钩子框架是一个轻巧的低级“插件”系统在不修改django项目原有代码的基础上可以全局改变django的输入或输出每个中间件组件负责执行某些特定功能。

因为中间件改变的是全局所以需要谨慎实用滥用的话会影响到服务器的性能

Django项目默认有一些自带的中间件每个中间件组件由字符串表示指向中间件工厂的类或函数名的完整

Python

[django.middleware.security.SecurityMiddleware,django.contrib.sessions.middleware.SessionMiddleware,django.middleware.common.CommonMiddleware,django.middleware.csrf.CsrfViewMiddleware,django.contrib.auth.middleware.Au***nticationMiddleware,django.contrib.messages.middleware.MessageMiddleware,django.middleware.clickjacking.XFrameOptionsMiddleware,

]自定义中间件

自定义中间件可以是一个函数也可以是一个类。

但是都要有接受get_response参数的入口。

如果中间件是在整个项目中使用的可以在manage.py同级目录下新建一个middleware.py文件

如果中间件是在某个子应用中使用的可以在子应用目录下新建一个middleware.py文件

def

my_middleware(get_response):def

自定义中间件逻辑print(视图函数之前执行的中间件逻辑)response

自定义中间件逻辑print(视图函数之后执行的中间件逻辑)return

responsereturn

get_response):self.get_response

get_responsedef

自定义中间件逻辑print(视图函数之前执行的中间件逻辑)response

自定义中间件逻辑print(视图函数之后执行的中间件逻辑)return

response#

[my_app.middleware.my_middleware,middleware.MyMiddleware1,注意中间件的执行顺序是从上到下也就是说先执行my_middleware再执行MyMiddleware1。

常用中间件

作用在视图函数执行前对请求进行预处理。

process_view()只能在类方法下的中间件使用。

入参

request请求对象view视图函数对象args视图函数的位置参数kwargs视图函数的关键字参数

返回值

如果返回None则继续执行视图函数如果返回一个响应对象则终止视图函数的执行并返回响应对象。

class

get_response):self.get_response

get_responsedef

self.get_response(request)return

response#

request.user.is_au***nticated:return

当项目进行维护时可能会出现一些URL需要临时关闭或者只允许特定IP访问这时就可以使用中间件进行URL过滤。

MAINTAIN_URL

get_response):self.get_response

get_responsedef

self.get_response(request)return

responseDjango生命周期

首先用户在浏览器中输入url发送一个GET/POST方法的request请求。

Django中封装了socket的WSGi服务器监听端口接受这个request

请求再进行初步封装然后将请求传送到中间件中这个request请求依次经过中间件对请求进行校验或处理再传输到路由系统中进行路由分发匹配相对应的视图函数(FBV/CBV)再将request请求传输到views中的这个视图函数中进行业务逻辑的处理调用modles中表对象通过orm获取数据库(DB)的数据通过templates中相应的模板进行渲染然后将这个封装了模板response响应传输到中间件中依次进行处理最后通过WSGi再进行封装处理响应给浏览器展示给用户

生命周期分析

在浏览器输入url譬如www.baidu.com浏览器会自动补全协议http变为http://www.baidu.com现在部分网站都实现了HSTS机制服务器自动从http协议重定向到https协议在网页中点击超链接或javascript脚本进行url跳转仅设置

href‘绝对路径’浏览器会自动使用当前url的协议、host和port譬如在

https://tieba.baidu.com/index.html网页中点击一个超链接/f?kwchinajoy

会自动访问

https://tieba.baidu.com/f?kwchinajoy

路由转发

IP查找因特网内每个公有IP都是唯一的域名相当于IP的别名因为我们无法去记住一大堆无意义的IP地址但如果用一堆有意义的字母组成大家就能快速访问对应网站DNS解析通过域名去查找IP先从本地缓存查找其中本地的hosts文件也绑定了对应IP若在本机中无法查到那么就会去请求本地区域的域名服务器通常是对应的网络运营商如电信/联通这个通过网络设置中的LDNS去查找如果还是没有找到的话那么就去根域名服务器查找这里有所有因特网上可访问的域名和IP对应信息根域名服务器全球共13台路由转发通过网卡、路由器、交换机等设备实现两个IP地址之间的通信。

用到的主要就是路由转发技术根据路由表去转发报文还有子网掩码、IP广播等等知识点

建立连接

通过TCP三次握手建立TCP连接三次握手的目的是建立可靠的通信信道确保数据包的顺序和完整性。

WSGIHandler处理请求

WSGIHandler是Django框架的WSGI服务器它是WSGI协议的实现它接收到请求后会将请求封装成environ字典然后交给Django的应用对象进行处理处理完后再将响应封装成response对象再交给WSGIHandler进行响应。

可以在项目下的wsgi.py文件中进行配置。

class

WSGIHandler(base.BaseHandler):request_class

WSGIRequestdef

**kwargs):super().__init__(*args,

**kwargs)self.load_middleware()def

__call__(self,

start_response):set_script_prefix(get_script_name(environ))signals.request_started.send(senderself.__class__,

self.request_class(environ)response

self.get_response(request)except

Exception

self.handle_uncaught_exception(request,

exc)...WSGIHandler的__call__方法接收两个参数environ和start_responseenviron是WSGI协议中的环境变量start_response是WSGI协议中的响应函数。

首先调用set_script_prefix方法设置脚本前缀这个方法的作用是设置当前请求的脚本路径譬如当前请求的url为http://www.baidu.com/index.html脚本路径为/index.html那么set_script_prefix(‘/index.html’)这样Django就知道当前请求的脚本路径。

然后调用signals.request_started.send方法发送一个request_started信号这个信号的作用是通知其他组件当前请求已经开始处理。

接着调用get_response方法获取响应对象这个方法的作用是调用中间件获取请求对象然后调用路由系统匹配对应的视图函数调用视图函数获取响应对象然后调用模板系统渲染响应对象最后返回给WSGIHandler。

最后调用start_response方法返回响应头WSGIHandler再将响应对象封装成WSGI协议的响应并返回给客户端。

middleware的process_request()方法,对request对象进行处理主要有以下方法一个中间件类最少需要实现下列方法中的一个

process_request:处理请求对象process_response:处理响应对象process_view:处理视图函数,在视图函数执行前对请求进行预处理process_exception:处理异常,在视图函数发生异常时对异常进行处理process_template_response:处理模板响应对象在模板响应对象被渲染前对响应对象进行处理

URLConf路由匹配通过urls.py文件中的urlpatterns列表匹配请求的url找到对应的视图函数调用视图函数获取响应对象。

如果找不到对应的视图函数就会触发异常由中间件的process_exception()方法进行处理。

middleware的process_view方法进行预处理views中的视图函数处理请求requestmodels处理views处理数据获取到数据后

将数据封装到context字典中,然后调用指定的template.html,通过模板中的变量、标签、过滤器等再结合传入数据context会触发中间件的process_template_response方法渲染出最终的响应内容。

或者不调用模板直接返回数据如JsonResponse,FileResponse等。

或者执行redirect,生产一个重定向的HttpResponse对象然后交给中间件的process_response方法进行处理。

middleware的process_response方法进行响应处理,返回到WSGIHandler类中。

至此django编程的处理部分完毕WSGIHandler类获取响应对象后

先处理response的响应行和响应头如Content-Type,Content-Length等。

然后调用start_response方法返回响应行和相应头到uWSGI这个start_response只能调用一次处理响应体将response.content写入到uWSGI的socket中等待客户端接收。

客户端接收到响应后做对应的操作如显示在浏览器中下载到本地保存到数据库等javascript处理。

Django日志

日志是记录程序运行过程中的事件的记录可以帮助我们分析程序的运行情况查找程序的错误提高程序的健壮性。

Django框架提供了日志系统通过pythonnative的logging模块来实现日志功能可以记录程序运行的详细信息包括错误信息、访问日志、SQL日志等。

logging主要由4个模块构成

loggers:记录器是进入日志记录系统的入口点。

每个记录器都是一个命名的可以将消息写入其中进行处理的存储桶。

handlers:Handler决定如何处理logger中的每条消息。

它表示一个特定的日志行为例如

将消息写入屏幕、文件或网络Socket。

filters:筛选器用于对从logger传递给handler的哪些日志要做额外控制。

Formatters:格式化器用于控制日志消息的格式。

logger日志有5个级别

DEBUG(10):调试信息用于调试程序。

INFO(20):一般信息用于记录程序的运行情况。

WARNING(30):警告信息用于记录程序的非期望行为。

ERROR(40):错误信息用于记录程序的错误。

CRITICAL(50):严重错误信息用于记录程序的崩溃或意外退出。

写入logger的每条消息都是一条日志。

每条日志也具有一个日志级别它表示对应的消息的验证性。

每个日志记录还可以包含描述正在打印的事件的元信息当一条消息传递给logger时消息的日志级别将与logger的日志级别进行比较。

如果消息的日志级别大于等于logger的日志级别该消息将会往下继续处理如果小于该消息将被忽略

Logger一旦决定消息需要处理它将传递该消息给一个Handler一般开发环境时会启用DEBUG级别而在生产环境中启用WARNING或ERROR级别

日志配置

Django的日志配置主要在settings.py文件中进行主要有以下几项配置

LOGGING

disable_existing_loggers:是否禁用现有的日志记录器默认为False。

disable_existing_loggers:

False,#

{format:[%(levelname)s][%(asctime)s][%(filename)s:%(lineno)d:%(funcName)s]

%(message)s},},#

django.utils.log.RequireDebugTrue,},},handlers:

{console:

logging.StreamHandler,formatter:strandard},file:

{level:

logs/django.log),formatter:verbose},},loggers:

日志处理器

propagate:是否向上更高level的logger传递日志信息默认为True。

propagate:

True,},},

my_view(request):logger.debug(This

debug

world!)handler对应的是个字典每一个key对应一个handler的名字每个value对应一个handler的配置

class(必须)表示handler的类名。

level(可选)表示日志的最低级别只有大于等于该级别的日志才会被处理。

formatter(可选)表示日志的格式。

filename(可选)表示日志文件的路径。

filters(可选)表示日志的过滤器。

python的logging模块提供了很多Handler,大部分在以下2个目录

logging/__init__.pylogging/handlers.py

StreamHandler:将日志输出到流可以是sys.stderr(控制台),sys.stdout或者文件。

FileHandler:将日志输出到文件。

继承自StreamHandler。

默认情况下文件无限追加RotatingFileHandler:当日志文件达到一定大小时自动切分日志文件默认情况下日志文件名为“日志文件名.log”切分后日志文件名为“日志文件名.log.1”“日志文件名.log.2”以此类推。

maxBytes:日志文件达到多少字节时自动切分。

backupCount:保留切分后的日志文件个数。

例如backupCount5基础文件名为app.log那么达到指定maxBytes之后会关闭文件app.log将app.log重命名为app.log.1如果app.log.1存在那么就顺推先将app.log.1重命名为app.log.2再将现在的app.log命名为app.log.1最大创建到app.log.5(旧的app.log.5会被删除)然后重新创建app.log文件进行日志写入也就是永远只会对app.log文件进行写入

注意启动项目使用命令:python

TimeRotatingFileHandler:按时间间隔切分日志文件默认情况下日志文件名为“日志文件名.log.日期.log”切分后日志文件名为“日志文件名.log.日期.log.1”“日志文件名.log.日期.log.2”以此类推。

‘S’(秒)‘M’(分)‘H’(时)‘D’(天)‘W0-W6’(星期)‘midnight’(每天凌晨)

interval:指定切分日志的时间间隔单位为when的单位。

backupCount:保留切分后的日志文件个数。

utcFalseFalse则使用当地时间True则使用UTC时间atTimeNone必须是datetime.time实例指定文件第一次切分的时间when设置为S,M,H,D时该设置会被忽略

SMTPHandler:通过邮件发送日志信息。

当项目出现严重错误时可以发送邮件通知管理员。

mailhost:邮件服务器地址默认25端口如(smtp.qq.com,

25)。

fromaddr:发件人地址。

toaddrs:收件人地址可以是字符串或列表。

subject:邮件主题。

credentials:登录邮件服务器的用户名和密码如果不需要登录可以设置为None。

secure:是否使用SSL加密连接。

timeout:连接邮件服务器的超时时间。

注意需要在settings.py中设置EMAIL_HOST,EMAIL_PORT,EMAIL_HOST_USER,EMAIL_HOST_PASSWORD等参数。

handlers:

logging.handlers.RotatingFileHandler,filename:

1024*1024*5,

保留5个日志文件formatter:standard},file_timed_rotating:

{level:

logging.handlers.TimedRotatingFileHandler,filename:

D,interval:

logging.handlers.SMTPHandler,formatter:standard,mailhost:

(smtp.qq.com,

设置-账户-POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV服务-生成授权码

过滤器用于从logger传递给handler的哪些日志要做额外控制。

默认情况下满足日志级别的任何消息都将处理。

只要级别匹配任何日志消息都会被处理。

不过也可以通过添加

filter

Filters还可以用于修改将要处理的日志记录的优先级。

例如如果日志记录满足特定的条件可以编写一个filter将日志记录从ERROR降为WARNING。

filter

RequireDebugTrue表示只有在DEBUG模式下才处理日志

filters:

django.utils.log.RequireDebugTrue,},

},loggers:

wordsNone):super().__init__(name)self.words

wordsdef

日志格式化formatter用于指定日志信息的输出格式。

默认情况下Django使用标准的日志格式化formatter格式为

[%(levelname)s][%(asctime)s][%(filename)s:%(lineno)d:%(funcName)s]

%(message)s其中

%(levelname)s日志级别名称%(asctime)s日志输出的时间%(filename)s日志输出的文件名%(lineno)d日志输出的行号%(funcName)s日志输出的函数名%(message)s日志输出的具体信息%(name)slogger的名称%(process)d进程ID%(thread)d线程ID%(module)s模块名

如果需要自定义日志格式化formatter可以修改settings.py中的formatters配置

formatters:

Django信号是一种在Django框架中用于处理事件通知的机制。

它可以让我们在某些特定事件发生时自动执行一些操作比如用户注册、订单创建等。

Django信号的机制是基于观察者模式它允许我们定义信号然后在其他地方触发信号让信号的接收者来执行相应的操作。

缓存失效当数据库数据发生变化时可以让缓存失效这样可以让用户看到最新的内容。

发送邮件当用户注册成功时可以发送欢迎邮件。

通知用户当订单状态发生变化时可以通知用户。

记录日志当用户登录、退出时可以记录日志。

内置信号

Django框架中内置了很多信号可以用于处理常见的事件通知。

分为模型信号、管理信号、请求信号、测试信号等。

模型信号

pre_save在保存对象之前触发。

post_save在保存对象之后触发。

pre_delete在删除对象之前触发。

post_delete在删除对象之后触发。

m2m_changed在多对多关系发生变化时触发。

pre_init在初始化对象之前触发。

post_init在初始化对象之后触发。

class_prepared在类准备好之后触发。

管理信号

pre_migrate在执行migrate命令之前触发。

post_migrate在执行migrate命令之后触发。

请求信号

request_started在请求开始时触发。

request_finished在请求结束时触发。

request_exception在请求发生异常时触发。

测试信号

setting_changed在设置改变时触发。

template_rendered在模板渲染完成时触发。

数据库包装器

首先需要定义一个接收器用于处理信号。

接收器必须是一个函数并且接收一个参数即信号发送者。

def

kwargs)然后可以选择手动连接接收器函数或者使用装饰器来实现。

手动连接接收器

request_finished.connect(my_signal_receiver,dispatch_uidmy_signal_receiver)

使用装饰器

request_finishedreceiver(request_finished)

def

导入signals模块严格来说信号处理和注册的代码可以放在任何你喜欢的地方一般可以放在子应用下的signals.py文件中。

自定义信号

my_view(request):my_signal.send(senderrequest,

dataHello,

Django缓存是一种提高网站性能的机制。

它可以缓存数据库查询结果、页面渲染结果、静态文件等从而减少数据库查询次数、加快页面响应速度。

数据库缓存Django提供了数据库缓存机制可以缓存查询结果减少数据库查询次数。

页面缓存Django提供了页面缓存机制可以缓存页面渲染结果加快页面响应速度。

静态文件缓存Django提供了静态文件缓存机制可以缓存静态文件加快网站访问速度。

——是在数据库中还是在文件系统上或者直接放在内存中。

这是一个重要的决定会影响缓存的性能是的有些缓存类型比其他类型快。

内存缓存Redis数据库数据库缓存文件系统缓存本地内存缓存虚拟缓存(用于开发模式)使用自定义缓存后端

安装Redis

redis默认不支持windows由于一般开发环境在windows因此在此下载一个windows版本

https://github.com/tporadowski/redis/releases

直接解压压缩包

6379直接在当前目录下打开cmd输入redis-server

redis.windows.conf

redis.windows.conf不要关闭cmd窗口redis服务会一直运行双击redis-cli.exe进入redis命令行

redis

缓存也可以指定任何数量的附加缓存。

如果你使用的是本地内存缓存以外的缓存后端或者你需要定义多个缓存则需要其他选项。

以下基本结构

CACHES

django.core.cache.backends.redis.RedisCache,#

缓存服务器地址LOCATION:

django.core.cache.backends.db.DatabaseCachedjango.core.cache.backends.dummy.DummyCachedjango.core.cache.backends.filebased.FileBasedCachedjango.core.cache.backends.locmem.LocMemCachedjango.core.cache.backends.memcached.PyMemcacheCachedjango.core.cache.backends.memcached.PyLibMCCachedjango.core.cache.backends.redis.RedisCache

OPTIONS

传递给缓存后端的额外参数。

可用的参数根据你的缓存后端不同而不同

TIMEOUT

300秒如果为None表示缓存永不超时如果为0表示缓存立刻超时相当于不使用缓存

全站缓存

缓存中间件django.middleware.cache.UpdateCacheMiddleware,#

表示其他中间件django.middleware.common.CommonMiddleware,django.middleware.cache.FetchFromCacheMiddleware,

从缓存中读取数据

缓存状态为200的GET和HEAD请求的响应除非响应头中设置不进行缓存对具有不同查询参数的相同URL的请求的响应被认为是各自不同的页面并且被分别单独缓存。

该中间件会使用与对应的GET请求相同的响应头来回答HEAD请求即可以为HEAD请求返回缓存的GET响应。

将数据更新到缓存中

定义的CACHE_MIDDLEWARE_SECONDS值GMT时间设置响应的Cache-Control的max-age值是定义的CACHE_MIDDLEWARE_SECONDS值。

如果视图设置了自己的缓存时间即设置了Cache-Control

max

django.views.decorators.cache可以设置视图的到期时间使用cache_control()装饰器代码cache_control(max_age3600)或禁用视图的缓存使用never_cache()装饰器代码never_cache如果USE_I18N设置为True则生成的缓存key将包含当前语言的名称这样可以轻松缓存多语言网站而无需自己创建缓存密钥。

如果

USE_L10N设置为True

用于存储的缓存别名(如’default’)CACHE_MIDDLEWARE_SECONDS

应缓存每个页面的秒数CACHE_MIDDLEWARE_KEY_PREFIX--

Django

通过多站点进行缓存共享请将此值设置为站点名或者设置成在Django

实例中唯一的其他字符串以此防止键冲突。

如果你不介意可以设置成空字符串

default

django_cache使用缓存因为要和redis交互所以需要安装redis

pip

Django的缓存可以设置缓存指定的视图只需要在视图函数上添加装饰器

cache_page()

minutes{time.time()})也可以在路由中设置缓存只需要在路由中添加

cache_page()

缓存超时时间单位秒如果为None那么就是永久缓存cache_key缓存的key不能使用变量只是一个字符串不要引号相当于CACHE_MIDDLEWARE_KEY_PREFIX

底层缓存

你的站点包含了一个视图它的结果依赖于许多费时的查询而且结果会随着时间变化而改变。

在这个情况下使用站点或视图缓存策略提供的全页面缓存并不理想因为不能缓存所有结果(一些数据经常变动)不过你仍然可以缓存几乎没有变化的结果

API

是一个字典包含了所有可用的缓存后端。

你可以通过缓存别名来访问缓存对象例如

from

True可以通过CACHES类似字典一样的方式访问settings中配置的缓存在同一个线程中重复请求相同的别名将返回相同的对象如果指定的

myalias

InvalidCacheBackendError为了线程安全性为会每个线程返回缓存的不同实例

作为快捷方式默认缓存可以通过django.core.cache.cache访问它等价于caches[default]

from

在views.py中有一个获取数据的函数这是主要的耗时操作我们可以用缓存来优化

from

get_cache_or_exec_func(cache_key,

func,

**kwargs):获取缓存如果缓存不存在则执行函数并缓存结果:param

cache_key:

启用session要应用session必须开启session中间层在settings.py中

MIDDLEWARE

原本自带django.contrib.sessions.middleware.SessionMiddleware,

设置session存储方式为cache

django.contrib.sessions.backends.cache在views.py中可以直接使用request.session来操作session也可以使用cache来缓存session

from

直接使用request.sessionrequest.session[name]

pdnbplusreturn

index_cache(request):session_data

cache.get(request.session.session_key)if

session_data:name

HttpResponse(name)具体例子假设我们的缓存后端是内存缓存LocMemCache以下是请求和响应的具体过程

用户访问

http://example.com/index服务器创建一个新的会话分配

session_key例如

http://example.com/index_cache服务器使用用户的

session_key

是一个分布式任务队列它可以用来处理异步任务比如发送邮件、执行数据库操作等。

它可以让你将耗时的任务交给

Celery

服务器的响应。

Celery是由Python开发、简单、灵活、可靠的分布式任务队列是一个处理异步任务的框架其本质是生产者消费者模型生产者发送任务到消息队列消费者负责处理任务。

Celery侧重于实时操作但对调度支持也很好其每天可以处理数以百万计的任务。

特点

简单熟悉celery的工作流程后配置使用简单高可用当任务执行失败或执行过程中发生连接中断celery会自动尝试重新执行任务快速一个单进程的celery每分钟可处理上百万个任务灵活几乎celery的各个组件都可以被扩展及自定制

Celery由三部分组成

消息中间件(Broker)官方提供了很多备选方案支持RabbitMQ、Redis、Amazon

SQS、MongoDB、Memcached等官方推荐RabbitMQ任务执行单元(Worker)任务执行单元负责从消息队列中取出任务执行它可以启动一个或者多个也可以启动在不同的机器节点这就是其实现分布式的核心结果存储(Backend)官方提供了诸多的存储方式支持RabbitMQ、

DjangoORM、Apache

任务模块Task包含异步任务和定时任务。

其中异步任务通常在业务逻辑中被触发并发往消息队列而定时任务由Celery

Beat进程周期性地将任务发往消息队列任务执行单元Worker实时监视消息队列获取队列中的任务执行Woker执行完任务后将结果保存在Backend中;

安装模块库

Celery的配置主要在celery.py文件中在项目根目录下创建celery.py文件

app

(tasks,brokerredis://localhost:6379/5,backendredis://localhost:6379/6,)app.task

装饰器注册任务

send_email(name):print(f准备执行任务:{name})print(执行任务中...)time.sleep(5)print(f执行任务完成:{name})return

OK1!app.task

send_sms(name):print(f准备执行任务:{name})print(执行任务中...)time.sleep(5)print(f执行任务完成:{name})return

celery

send_sms.delay(pd666)print(rs1.id)print(rs2.id)if

__name__

datetime.datetime.utcfromtimestamp(c_time.timestamp())#

utc_time

send_email.apply_async(args[pdnbplus,],etaexec_time)print(rs1.id)rs2

send_msg.apply_async(args[pd666,

pd888],etaexec_time)print(rs2.id)if

__name__

AsyncResult(iddb514dcc-5db3-48e3-a065-399207d76ce9,

appapp)if

async_result.successful():result

async_result.get()print(result)

elif

async_result.failed():print(执行失败)

elif

STARTED:print(任务已经开始被执行)Django集成Celery

Django集成Celery步骤如下

在settings.py文件增加Celery基本设置在子应用下创建celery.py文件设置Celery对象在子应用包中

init.py

增加代码加载Celery对象在子应用增加task.py文件定义要执行的任务启动work

更多配置

https://docs.celeryq.dev/en/latest/userguide/configuration.html

Celery配置#

Asia/Shanghai在项目下创建celery.py文件设置Celery对象

import

os.environ.setdefault(DJANGO_SETTINGS_MODULE,

项目名.settings)

celery_app.config_from_object(django.conf:settings)

自动注册任务

会注册settings.INSTALLED_APPS所有app下的tasks.py文件中的任务

celery_app.autodiscover_tasks(lambda:

__init__.py

[celery_app]在子应用tasks.py文件中定义任务

from

send_email(name):print(f准备执行任务:{name})print(执行任务中...)time.sleep(5)print(f执行任务完成:{name})return

OK1!celery_app.task

send_sms(name):print(f准备执行任务:{name})print(执行任务中...)time.sleep(5)print(f执行任务完成:{name})return

OK2!在项目路径下启动work

Django任务交给Celery的方法和普通使用Celery任务的调用基本无区别只是将执行代码的放到到View视图中

而获取结果往往并不能把结果和第1次请求一起响应若想获取结果是通过第2次请求获取结果

from

send_email.delay(pdnbplus)work_id2

HttpResponse(已经执行了异步任务,ID:{work_id1}{work_id2})def

HttpResponse(f任务的结果是:{result})Celery

绑定参数

Celery可通过task绑定到实例获取到task的上下文这样我们可以在task运行时候获取到task的状态记录相关日志等

在装饰器中加入参数

bindTrue在task函数中的第一个参数设置为selfself对象是celery.app.task.Task的实例可以用于实现重试等多种功能

在子应用tasks.py文件中定义任务

celery_appcelery_app.task(bindTrue)

def

add(self,x,y):try:print(f准备执行任务:{x}{y})print(self)print(f{self.name},

Exception(测试异常)

Celery在执行任务时提供了钩子方法用于在任务执行完成时候进行对应的操作在Task源码中提供了很多状态钩子函数如on_success(成功后执行)、on_failure(失败时候执行)、on_retry(任务重试时候执行)、after_return(任务返回时候执行)

z在子应用tasks.py文件中定义任务

kwargs):print(f任务{task_id}执行成功结果是{retval})def

on_failure(self,

einfo):print(f任务{task_id}执行失败异常是{exc})def

on_retry(self,

einfo):print(f任务{task_id}执行失败异常是{exc})shared_task(baseMyTask,bindTrue)

def

x,y):print(f准备执行任务:{x}{y})return

xyCelery

在很多情况下一个任务需要由多个子任务或者一个任务需要很多步骤才能完成Celery也能实现这样的任务完成这类型的任务通过以下模块完成

group:

类似group但分header和body2个部分header可以是一个group任务执行完成后调用body的任务

实际应用场景

统计用户的行为数据需要先获取用户的ID再获取用户的行为数据最后汇总统计数据

在子应用tasks.py文件中定义任务

add(x,y):print(计算两个数的和)time.sleep(5)print(计算完成)return

xyshared_task

mul(x,y):print(计算两个数的积)time.sleep(5)print(计算完成)return

x*ygroup:

HttpResponse(f并行调度任务结果是{rs})如果想将这个并行调用任务改为异步可以将逻辑封装到tasks中然后用异步调用

在另一个视图中获取结果

do_group_task.AsyncResult(id).get()

chain:

HttpResponse(f链式调用任务结果是{rs})chord:

在子应用views.py文件中调用任务

类似group但分header和body2个部分header可以是一个group任务执行完成后调用body的任务chord_result

chord((add.s(i,i)

HttpResponse(fchord调用任务结果是{rs})Celery

任务监控

celery通过flower来监控任务的执行情况flower是一个web界面可以查看任务的执行情况、任务的依赖关系、任务的历史记录、任务的统计数据等。

文档https://flower.read***docs.io/en/latest

安装flower

DebugToolbar是一个Django的插件可以用来调试和分析Django的请求和响应包括SQL查询、模板渲染、缓存命中率、请求时间、内存占用、日志记录等。

文档https://django-debug-toolbar.read***docs.io/en/latest/

安装DebugToolbar

django-debug-toolbar3.7.0在settings.py文件中进行配置

INSTALLED_APPS

...django.contrib.staticfiles,#

...

django.template.backends.django.DjangoTemplates,APP_DIRS:

True,#

...debug_toolbar.middleware.DebugToolbarMiddleware,#

...

调试工具栏只会允许特定的ip访问在settings的INTERNAL_IPS中配置

INTERNAL_IPS

]这个中间件尽可能配置到最前面但是必须要要放在处理编码和响应内容的中间件后面比如我们要是使用了GZipMiddleware就要把DebugToolbarMiddleware放在GZipMiddleware后面

在项目urls.py文件中增加debug_toolbar的url配置

from

作为路径访问可以设置任意的路径名只要能轻易区分一般应用path(__debug__/,

urlpatterns启动服务器访问http://127.0.0.1:8000/xxx/

DebugToolBar

当前请求的相关信息视图函数Cookie信息Session信息等SQL:查看当前界面执行的SQL语句StaticFiles当前界面加载的静态文件Templates:当前界面用的模板Cache缓存信息Signals信号Logging当前界面日志信息Redirects当前界面的重定向信息Profiling查看视图函数的信息

面板配置

debug_toolbar.settings.CONFIG_DEFAULTS

debug_toolbar.settings.PANELS_DEFAULTS

将下列配置添加到settings.py文件中把不想要的去掉即可

DEBUG_TOOLBAR_PANELS

[debug_toolbar.panels.history.HistoryPanel,debug_toolbar.panels.versions.VersionsPanel,debug_toolbar.panels.timer.TimerPanel,debug_toolbar.panels.settings.SettingsPanel,debug_toolbar.panels.headers.HeadersPanel,debug_toolbar.panels.request.RequestPanel,debug_toolbar.panels.sql.SQLPanel,debug_toolbar.panels.staticfiles.StaticFilesPanel,debug_toolbar.panels.templates.TemplatesPanel,debug_toolbar.panels.cache.CachePanel,debug_toolbar.panels.signals.SignalsPanel,debug_toolbar.panels.logging.LoggingPanel,debug_toolbar.panels.redirects.RedirectsPanel,debug_toolbar.panels.profiling.ProfilingPanel,

]工具栏配置

覆盖默认配置分为2部分一部分适用于工具栏本身另一部分适用于某些特定面板

DEBUG_TOOLBAR_CONFIG

{debug_toolbar.panels.redirects.RedirectsPanel},INSERT_BEFORE:

/body,RENDER_PANELS:

False,SHOW_TOOLBAR_CALLBACK:debug_toolbar.middleware.show_toolbar,#

Panel

SocketServer,threading,wsgiref,debug_toolbar,django.db,django.core.handlers,django.core.servers,django.utils.decorators,django.utils.deprecation,django.utils.functional,),PROFILER_MAX_DEPTH:

admin/widgets/),SQL_WARNING_THRESHOLD:

500,

{‘debug_toolbar.panels.redirects.RedirectsPanel’}

INSERT_BEFORE:

此设置是要在哪个HTML元素之前插入工具栏的JavaScript。

RENDER_PANELS:

调试工具栏将把面板的内容保留在服务器上的内存中并按需加载它们。

如果设置为

True

则会在每个页面内呈现面板。

这可能会降低页面呈现速度但在多进程服务器上需要这样做例如如果在生产中部署工具栏不建议这样做。

默认值

None

告诉工具栏自动执行正确的操作具体取决于WSGI容器是否运行多个进程。

此设置允许您在需要时强制执行不同的操作。

RESULTS_CACHE_SIZE:

此设置将注入根模板div中以避免与客户端框架发生冲突。

例如将调试工具栏与Angular.js一起使用时将其设置为

‘ng-non-bindable’

debug_toolbar.middleware.show_toolbar

这是用于确定工具栏是否应显示的函数路径默认检测DEBUG设置为True并且访问IP必须在INTERNAL_IPS中代码如下(可以设置自定义的检测函数路径)

def