1
yanshenxian 2020-08-14 13:09:26 +08:00
生产队列用的是什么?为啥只担心消费积压却不担心生产积压?
|
2
Jooooooooo 2020-08-14 13:14:29 +08:00
建议用推送的方案
你可以维护消费者的列表, 然后实时上报自己的资源, 有资源运行任务再推给这个消费者, 不会有等待的问题 |
3
wysnylc 2020-08-14 13:15:07 +08:00
@yanshenxian #1 吸管到底是一个洞还是两个洞?
|
4
yanshenxian 2020-08-14 13:25:43 +08:00
@wysnylc 不审题 ? 生产者任务队列 和 消费者的线程池队列 是几个洞?
|
5
zhady009 OP @yanshenxian 业务场景不一样 现在的任务顶多几百个 但是每个时长都不确定 有的很长有的很短 处理长的不能妨碍短的
|
6
yanshenxian 2020-08-14 14:01:43 +08:00
我觉得你需要大概确定任务执行的时间,然后分级处理。像 #2 一样,你还得有消费者扩容策略
要不然你的任务还是会积压在哪里没法处理,不管是积压在生产者队列里,还是积压在消费者端。 |
7
zhady009 OP @yanshenxian 我觉得这 2 种都行,还是看看实现的具体方式 任务堆积的话会有警报给运维
现在的业务规模大部分情况都不会堆积, 主要是为 11.11 做准备 |
8
silenzio 2020-08-14 14:53:54 +08:00
插个眼, 我最近也有这个需求, 不过是多个进程
计划是消费者进程主动去生产者进程里拿 (消费者进程数量为个位数, grpc 去拿), 除了轮循还有别的更好的办法吗? |
9
kkkkkrua 2020-08-14 19:04:07 +08:00
除了轮询,还一个就是要生产者新增了消息后告诉消费者去消费,不知道你们啥架构,我觉得在这一点上,可以用 push 的方式支撑,可以用多个模式的中间件来考虑这个问题
|
10
ChovyChu 2020-08-15 10:37:39 +08:00
rockermq 支持 pull,资源的问题直接判断线程池运行的线程数?或者用 push 的方式,如果线程池已经满了则 requeue 。
|