大量查询数据任务，通过 kafka 缓冲后入库，如何解决大任务阻塞小任务的情况。

优先级队列
小任务->高优先级
大任务->低优先级

无视我

不对，我没理解
[想请教各位大神这类场景有什么策略解决大任务阻塞小任务入库的问题，或者有没其他 mq 替换 kafka ，支持创建大量 topic ，每个任务对应一个 topic ，且不影响 mq 性能。]
每个任务对应一个 topic 的目的是什么呢？

@q1angch0u 这样任务之间的影响相对较少 每个任务在查询环节创建 taskid 为名称的 topic ，并通知入库服务去消费该 topic ， 任务完成后可以删除该 topic

@whats kafka 有这么用的吗……

for {
task = get_task_form_small_topic()
if task {
do(task)
continue
}
task = get_task_form_big_topic()
do(task)
}

你已经分大小任务 topic 了,这样不行吗?

小的优先级高的新建到不同 topic ， 让分一些入库服务专门消费这些 topic

你这个查询做两件事：
1. 查到不同源的数据入库。
2. 返回数据条数。

这样用 kafka 确实有点奇怪

1. 不能直接计算条数，然后写 kafka 么？
2. 能不能实时从数据库取出条数，写了几条就能拿到几条。
3. 数据预查预写

加 topic 成本最低.

为什么会阻塞？大概率是大批量写入占用了磁盘 iIO

仅供参考：
1.挂载多个磁盘，然后配置多个 data 目录
2.topic 分区

ps: 1.我不理解什么叫”并通知入库服务去消费该 topic “这句话，topic 有数据就自动消费就好了 offset 会自动记录，为啥要通知？？
2.奇葩场景、奇葩用法

槽点太多。。。。
大任务大部分都是大于 1w 的都是到 tp2 ，小任务到 tp1 ，消费从 tp1 和 tp2 消费怎么可能会被大任务阻塞？

1 亿的数据对于 kafka 来说挺小的吧....10 亿一天都没多少，没理解为什么要这么用

我很好奇，你现在这样设计，那用户多久才能得到查询结果？

到底是什么业务场景？

给所有任务的入库设置超时时间，超时的任务 cancel 掉，超时的视为大任务，大任务单独放到重试队列里，这样不会阻塞中小任务。

rabbitmq 不是支持优先级队列吗？

分开消费呗.

分批生产到两个 topic ，不同消费者组消费，怎么会阻塞呢，我想到的原因就 broker 性能实在太差，或者根本没形成 Cluster

『需等大任务入库完成才能入库』

你这儿的入库指的是你 kafaka 后面的那个消费者（入库服务）吗？那既然这样为何不增加一些消费者的实例？

1. "1w 条提交给 topic1,小于 1w 条提交给 topic2"，分两个 topic 是有业务含义吗？如果没有的话这个逻辑是很有问题的。
2. "1w 条写 topic"是在 kafka 里写了 1w 条，还是写了一条，里边放了 1w 条数据？如果是后者，这样做是非常有问题的。
3. 你的 kafka 集群有多大？该 topic 分区有多少？听起来好像只有一个分区？有分区逻辑吗？比如你完全可以根据数据量写到不同的分区，而不是创建两个 topic 。
4.至于你说的“每个任务对应一个 topic ，用完删除”的想法更是有点异想天开。首先 kafka 已经是吞吐量最高的 mq ，且吞吐量不受存储数据量影响。其次，“用完删除”没有意义，高性能的分布式数据库 mq 等基本都是标记删除，而且高吞吐 mq 的数据都是放在磁盘的，删除 topic 只是个手动腾出磁盘空间的操作，有什么意义？

总之你遇到的问题不是 kafka 的问题，也不是换个 mq 可以解决的问题。看看 kafka 的性能瓶颈在哪里，可能是分区、网络 io 、内存之类的。

请使用消息队列。kafka 适合有序消息流处理。