标签：redis 代码 模式 地址 基于 同步 arch async 复杂
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
标签：redis 代码 模式 地址 基于 同步 arch async 复杂
原文地址：https://www.cnblogs.com/harrychinese/p/flask_async_approach.html
