最近在学 celery,想用在一个 django 项目上,有些问题还没搞懂。
看到 celery 有一个应用场景是,解决高并发的请求任务,具体就是如果同一时间有多用户同时请求,这些请求会交给 celery 异步执行,用户不用等待,结果执行完会通知用户。那么 celery 是否可以解决并发操作数据库的问题?还是说这里的并发本质并不一样?
1
vicalloy 2021-02-03 14:24:47 +08:00
celery 就是异步队列。
在面对短时间的大流量时,可以把任务放到队列里排队。 如果只是简单的数据库操作是没必要用到 celery 的。 |
2
fansfans 2021-02-03 14:25:16 +08:00
celery 是削峰 并不是提升数据库的并发
|
3
maocat 2021-02-03 14:28:46 +08:00
celery 是一个任务队列,主要是将耗时任务新起一个线程执行,比如发送验证码,读取文件
|
4
karatsuba 2021-02-03 14:57:44 +08:00
写个发邮件吧
|
5
wuwukai007 2021-02-03 15:15:48 +08:00
celery 是消息队列 + 任务处理的 集合
|
6
Rob007 2021-02-03 15:17:08 +08:00
websocket 向前端推
|
7
tmackan 2021-02-03 15:22:01 +08:00
celery 用解耦请求核心流程的 或者用来晓峰
celery 是否可以解决并发操作数据库的问题?具体要看你的 celery 任务是来干啥的! 是来发邮件,还是发报警,还是干啥的。 其实就是异步解耦核心流程~ |
8
allisone 2021-02-03 15:25:36 +08:00
celery 挺不错的,也有一个类似的 dramatiq 的异步任务队列
|
9
mckelvin 2021-02-03 15:55:46 +08:00 8
用 Celery 前:
1. 用户发请求 2. 服务端接受处理 3. 服务端处理(花很长时间) 4. 用户收到结果 用 Celery 后: 1. 用户发请求 2. 服务端把接受请求 3. 服务端把要处理的函数以及参数丢到 task queue,并获得一个 task id (很快) 4. 用户收到 task id(您的请求已受理,但是还没有完成,但你可以用 task id 来查询结果,如果你不需要知道执行结果的话就不用再查了) 用户发多少请求用户说了算,但是具体什么时间真正处理这个请求里的操作服务端说了算。celery 比较适用于比较慢(不管是慢在 I/O 还是慢在 CPU )的操作,这种操作用户并不急着要结果,但是他在乎的是服务端收到这个请求,并且会在一定时间后完成这个操作。 如果是一个几秒内(不会积压一堆)就可以完成的慢操作,慢在 I/O 同时用户急着要(客户端同步在等待) ,那服务端用 asyncio 就可以同时更好支持多个用户并发,并不一定要用 celery, 用 celery 的话比较重了没必要。你说的数据库并发应该用 asyncio 去解决,可以理解为同一个进程内部做了个 celery 但是只适用于 I/O 慢的场景。如果不想写 asyncio 代码,只想写同步代码,那用 gevent 也可以。asyncio 的本质是把一个 blocking (阻塞) 的动作转换成 non-blocking (非阻塞):需要等待的时候不要让调用者等待,而是直接告诉调用者你先忙别的我还要一会儿才完事儿。 > 用户不用等待,结果执行完会通知用户。 通知这个过程默认是不存在的,还是得请求发起方凭 task id 去查询结果。或者实现一个对应的 [backend]( https://docs.celeryproject.org/en/stable/internals/reference/celery.backends.rpc.html) 让 celery 通知到这个地方。 |
11
renmu123 2021-02-03 18:12:19 +08:00 via Android
削谷平峰
|