导读：今天首席CTO笔记来给各位分享关于Django如何使用线程池使用的相关内容，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
Django配置Celery执行异步和同步任务（tasks））
celery是一个基于python开发的简单、灵活且可靠的分布式任务队列框架，支持使用任务队列的方式在分布式的机器/进程/线程上执行任务调度。采用典型的生产者-消费者模型，主要由三部分组成：
比如系统上线前后台批量导入历史数据，发送短信、发送邮件等耗时的任务
1.安装RabbitMQ，这里我们使用RabbitMQ作为broker，安装完成后默认启动了，也不需要其他任何配置
Ubuntu linux安装
CentOS Linux 安装
苹果mac 安装需要配置
配置环境变量 (苹果用户)
启动rabbitmq-server
2.安装celery
3.celery用在django项目中，django项目目录结构(简化)如下
4.创建 oa/celery.py 主文件
5.在 oa/__init__.py 文件中增加如下内容，确保django启动的时候这个app能够被加载到
6.各应用创建tasks.py文件，这里为 users/tasks.py
7.views.py中引用使用这个tasks异步处理
8.启动celery
9.这样在调用post这个方法时，里边的add就可以异步处理了
定时任务的使用场景就很普遍了，比如我需要定时发送报告给老板~
1. oa/celery.py 文件添加如下配置以支持定时任务crontab
3.启动celery beat，celery启动了一个beat进程一直在不断的判断是否有任务需要执行
django 多线程 + uWSGI 多线程 遇到的坑
当django中使用了多线程时，由于uwsgi默认不开启多线程，所以我们需要为uwsgi手动开启多线程。
闲言少叙，直接上配置。
在uwsgi 的配准文件 uwsgi.ini 中 增加下面的 threads 字段
这样就可开启多线程。
django部署的一个爬虫服务。客户端发送一个请求后，django立即开启一个线程，去执行耗时的爬虫任务， django不等待爬虫结果，便先返回给客户端“请等待”的提示，在爬虫任务执行完毕后，再通过轮询或websocket返回给客户端爬虫任务的结果。
使用 django的 runserver 运行项目没问题，但当使用 nginx+ uwsgi 运行项目时，爬虫的HTTP请求不返回结果；当使用 uwsgi单独拉起项目时，爬虫的HTTP返回结果但速度奇慢。
最后发现是uwsgi 默认不支持多线程，需要开启多线程（方法如上），即可解决问题。
Django源码阅读 (一) 项目的生成与启动
诚实的说，直到目前为止，我并不欣赏django。在我的认知它并不是多么精巧的设计。只是由功能堆积起来的"成熟方案"。但每一样东西的崛起都是时代的选择。无论你多么不喜欢，但它被需要。希望有一天，python能有更多更丰富的成熟方案，且不再被诟病性能和可维护性。（屁话结束）
取其精华去其糟粕，django的优点是方便，我们这次源码阅读的目的是探究其方便的本质。计划上本次源码阅读不会精细到每一处，而是大体以功能为单位进行解读。
django-admin startproject HelloWorld 即可生成django项目，命令行是exe格式的。
manage.py 把参数交给命令行解析。
execute_from_command_line() 通过命令行参数，创建一个管理类。然后运行他的 execute() 。
如果设置了reload，将会在启动前先 check_errors 。
check_errors() 是个闭包，所以上文结尾是 (django.setup)() 。
直接看最后一句 settings.INSTALLED_APPS 。从settings中抓取app
注意，这个settings还不是我们项目中的settings.py。而是一个对象，位于 django\conf\__init__.py
这是个Settings类的懒加载封装类，直到 __getattr__ 取值时才开始初始化。然后从Settings类的实例中取值。且会讲该值赋值到自己的 __dict__ 上（下次会直接在自己身上找到，因为 __getattr__ 优先级较低）
为了方便debug，我们直接写个run.py。不用命令行的方式。
项目下建个run.py，模拟runserver命令
debug抓一下setting_module
回到 setup() 中的最后一句 apps.populate(settings.INSTALLED_APPS)
开始看 apps.populate()
首先看这段
这些App最后都会封装成为AppConfig。且会装载到 self.app_configs 字典中
随后，分别调用每个appConfig的 import_models() 和 ready() 方法。
App的装载部分大体如此
为了方便debug我们改写下最后一句
res的类型是 Command django.contrib.staticfiles.management.commands.runserver.Command object at 0x00000101ED5163A0
重点是第二句，让我们跳到 run_from_argv() 方法，这里对参数进行了若干处理。
用pycharm点这里的handle会进入基类的方法，无法得到正确的走向。实际上子类Commond重写了这个方法。
这里分为两种情况，如果是reload重载时，会直接执行 inner_run() ，而项目启动需要先执行其他逻辑。
django 项目启动时，实际上会启动两次，如果我们在项目入口(manage.py)中设置个print，会发现它会打印两次。
第一次启动时， DJANGO_AUTORELOAD_ENV 为None，无法进入启动逻辑。会进入 restart_with_reloader() 。
在这里会将 DJANGO_AUTORELOAD_ENV 置为True，随后重启。
第二次时，可以进入启动逻辑了。
这里创建了一个django主线程，将 inner_run() 传入。
随后本线程通过 reloader.run(django_main_thread) ，创建一个轮询守护进程。
我们接下来看django的主线程 inner_run() 。
当我们看到wsgi时，django负责的启动逻辑，就此结束了。接下来的工作交由wsgi服务器了
这相当于我们之前在fastapi中说到的，将fastapi的app交由asgi服务器。(asgi也是django提出来的，两者本质同源)
那么这个wsgi是从哪来的？让我们来稍微回溯下
这个settings是一个对象，在之前的操作中已经从 settings.py 配置文件中获得了自身的属性。所以我们只需要去 settings.py 配置文件中寻找。
我们来寻找这个 get_wsgi_application() 。
它会再次调用 setup() ，重要的是，返回一个 WSGIHandler 类的实例。
这就是wsgiapp本身。
load_middleware() 为构建中间件堆栈，这也是wsgiapp获取setting信息的唯一途径。导入settings.py，生成中间件堆栈。
如果看过我之前那篇fastapi源码的，应该对中间件堆栈不陌生。
app入口→中间件堆栈→路由→路由节点→endpoint
所以，wsgiapp就此构建完毕，服务器传入请求至app入口，即可经过中间件到达路由进行分发。
django 使用全局线程池
系统里面有频繁的异步操作，每次触发异步操作就会开始一个新的线程处理相关逻辑，逻辑集中在I/O密集型；频繁的新建/销毁线程，消耗大量资源；由此，考虑使用线程池替换现有逻辑。
经过查询资料，python有ThreadPoolExecutor( tomorrow )可以直接实现线程池的相关功能，它的使用方式
具体使用方法见 ThreadPoolExecutor
ThreadPoolExecutor建立的线程池会先启动若干数量的线程，并让这些线程都处于睡眠状态，当向线程池submit一个任务后，会唤醒线程池中的某一个睡眠线程，让它来处理这个任务，当处理完这个任务，线程又处于睡眠状态。减少了建立销毁线程池消耗
在本项目里面的实现如下（定义的装饰器）
总体的原则是: CPU密集型任务应配置尽可能小的线程，尽量跟CPU的个数相近；IO密集型任务应配置尽可能多的线程，因为IO操作不占用CPU，不要让CPU闲下来，应加大线程数量。推荐的公式：
结语：以上就是首席CTO笔记为大家整理的关于Django如何使用线程池使用的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～