关于消费者主动拉取任务队列中的问题

[zhady009]

有一个生产者 通过调度服务每 3 分钟往任务队列里塞

然后消费者集群需要主动去拉取任务去消费,不用推送的方式是因为不能某个任务处理时间长导致后面的任务在消费者的线程池队列中待太久.

问题是有没有一种比较好的取任务队列里的任务 还是就轮询?, 取任务的条件是消费者有资源去消费这个任务.

[yanshenxian]

生产队列用的是什么？为啥只担心消费积压却不担心生产积压？

[Jooooooooo]

建议用推送的方案

你可以维护消费者的列表, 然后实时上报自己的资源, 有资源运行任务再推给这个消费者, 不会有等待的问题

[wysnylc]

@yanshenxian #1 吸管到底是一个洞还是两个洞?

[yanshenxian]

@wysnylc 不审题 ? 生产者任务队列 和 消费者的线程池队列 是几个洞？

[zhady009]

@yanshenxian 业务场景不一样 现在的任务顶多几百个 但是每个时长都不确定 有的很长有的很短 处理长的不能妨碍短的

[yanshenxian]

我觉得你需要大概确定任务执行的时间，然后分级处理。像 #2 一样，你还得有消费者扩容策略
要不然你的任务还是会积压在哪里没法处理，不管是积压在生产者队列里，还是积压在消费者端。

[zhady009]

@yanshenxian 我觉得这 2 种都行,还是看看实现的具体方式 任务堆积的话会有警报给运维
现在的业务规模大部分情况都不会堆积, 主要是为 11.11 做准备

[silenzio]

插个眼, 我最近也有这个需求, 不过是多个进程
计划是消费者进程主动去生产者进程里拿 (消费者进程数量为个位数, grpc 去拿), 除了轮循还有别的更好的办法吗?

[kkkkkrua]

除了轮询，还一个就是要生产者新增了消息后告诉消费者去消费，不知道你们啥架构，我觉得在这一点上，可以用 push 的方式支撑，可以用多个模式的中间件来考虑这个问题

[ChovyChu]

rockermq 支持 pull，资源的问题直接判断线程池运行的线程数？或者用 push 的方式，如果线程池已经满了则 requeue 。