这是一个创建于 502 天前的主题，其中的信息可能已经有所发展或是发生改变。
想到一个情况，请教一下各位大佬。
一个服务，内部有很多异步任务，如何确保异步任务的正确执行。
如果采用线程池，那么为了确保不同类型的任务不会相互抢资源，就会创建很多线程池，每个类型的任务一个线程池，相同类型的任务用一个线程池自己内部竞争。
如果采用 mq ，那么每种类型任务需要一个 topic ，然后视情况看各模块消费后是串行处理还是并行处理。
如果采用 mq ，并且后续是并行处理，那么就是 mq 和线程池的结合。
按照这个思路考虑下去，要给服务越来越大后，最终，是不是会尝试大量的线程池配置或者大量的 topic ，写各种消费者去消费。
请假一下各位大佬，实际项目上，如何解决此类问题呢？谢谢
一个服务，内部有很多异步任务，如何确保异步任务的正确执行。
如果采用线程池，那么为了确保不同类型的任务不会相互抢资源，就会创建很多线程池，每个类型的任务一个线程池，相同类型的任务用一个线程池自己内部竞争。
如果采用 mq ，那么每种类型任务需要一个 topic ，然后视情况看各模块消费后是串行处理还是并行处理。
如果采用 mq ，并且后续是并行处理，那么就是 mq 和线程池的结合。
按照这个思路考虑下去，要给服务越来越大后，最终，是不是会尝试大量的线程池配置或者大量的 topic ，写各种消费者去消费。
请假一下各位大佬，实际项目上，如何解决此类问题呢？谢谢
 | 1 Ehco1996 2024-06-03 16:43:16 +08:00 看复杂度和需求 mq 其实就是外存，能保证程序 crash 之后也不丢，放线程池里就是完全相反的 |
 | 2 kanepan19 2024-06-03 16:55:23 +08:00 如果异步任务重要， 用个用建一个任务表，用状态去维护他。 无论是，线程池还是 mq 都行。 我个人觉的，不是很复杂的任务，丢线程池挺方便。 mq 拿到的任务，执行一半，重启了，还是执行失败，当然影响范围比较小。 |
 | 3 xinshoushanglu 2024-06-03 17:20:37 +08:00 如果 任务不能丢失，有可靠性需求，那么不能用线程池 否则服务一重启发布 就丢了。 反之不重要的话，如果有任务队列的 控制需求，比如控制执行到一半任务 想暂停，过段时间继续，那么还得用 MQ 控制 offset 。 如果既不在意 任务丢失，也没有中途控制需求，只需要快点跑完眼前这批任务，那直接用线程池更合适，不用引入外部依赖来增加系统复杂度 |
 | 4 vivisidea 2024-06-03 21:38:52 +08:00 很多异步任务是什么量级？几千个？几万个？几十万个？ 线程池还是 mq ，我理解这两个并不是同一个角色，mq 的作用是分发任务，线程池是执行任务，或许你是想问 “是用单独的 mq 队列给 task 排队，还是用线程池内置的 blockingQueue 给 task 排队？” |
Select Language