web网站包含前端和后端, 异步处理可以用在前端, 也可以用在后端. 前端 jquery 进行 ajax 请求时, 可设置 async 属性为 true, 并为 success 设置一个 callback 函数, 在服务端返回之前, 浏览器可以执行 ajax 之后的代码, 当服务器端返回后, jquery会执行 success 回调.
后端的视图函数也可以引入这种异步处理机制, 发扬广大的是nodejs了, nodejs web服务单线程异步处理方式, 一般来讲, nodejs 框架的并发性要比Django/Flask 要好, 主要原因是 Django/Flask 都是基于 WSGI 同步处理模式的, WSGI 采用多线程方式来支持并发, 和协程相比, 多线程资源消耗要大的多, 所以并发性要差一些. 当然如果我们的 Django/Flask web应用配合 Gunicorn(高性能的WSGI服务器) 和 nginx(高性能Web服务器) 部署, 并发也会有一定的改善.
为了改善 flask 的并发, flask 社区主要尝试了两个方向:
1. 尝试在 flask 中引入 async 机制, 比如 flask_aiohttp 项目, 在python 中 async 和 sync 编程分别属于两个世界, 所以整合起来难度和稳定性都成问题, 目前该方向已经被放弃.
2. 将耗时的视图交由 celery 作异步处理, 其他视图仍采用同步方式. celery 可以采用 redis 做 back end. 这个机制优缺点都很明显, 优点是, 在没有增加编码复杂度的情形下, 可以明显改善并发处理能力, 缺点是, 引入了两个 celery 和 redis 两个集群, 增加了部署和运维复杂度.
目前方向2应该是正解, 交由celery的异步视图函数, 和使用 async-await 的异步还有有一些差异的, 最主要的是使用异步 celery task的视图函数, 在触发task后返回到视图函数, 而调用async任务后, 视图函数并不会马上得到代码执行权, 直到async任务完成后, 才能得到代码执行权.
所以, 使用 celery 的异步api, 通常仅仅是触发后台任务, 通常还有一个配套的api, 用来查询后台任务的status.
详见:
https://blog.miguelgrinberg.com/post/using-celery-with-flask
http://allynh.com/blog/flask-asynchronous-background-tasks-with-celery-and-redis/
windows 下的开发:
celery 采用 3.1.25 版本, 之后的 celery 不支持 window平台.
Redis-x64-3.0.504.msi 下载地址 https://github.com/MicrosoftArchive/redis/releases
原文地址：https://www.cnblogs.com/harrychinese/p/flask_async_approach.html