关于线程池在高并发场景下落地使用的疑惑？

对，你是对的，需要加机器

外部接口调用是 IO 密集型，并不会耗费很多 CPU ，尝试把线程池调大，使用 callback 而不是直接 get 结果，另外资源限制也是一方面，评估单机承受的压力，必要时扩容，最后，第三方接口也可能扛不住，需要做压力评估

需要等结果的场景，不适合用异步。 异步只适用于不需要等结果的场景，主要是为了快速响应的。

而且你这种情况，对顺序也有严格的要求吧，你可能需要等 A 接口返回了，用 A 接口的返回结果去执行下一步 调 B 接口，用 B 的返回结果调 C 接口对吧？ 如果是这样的话，那多线程的意义就更是彻底被玩没了， 反正都要等了为什么还要用线程？

如果不需要等，对顺序没有任何要求，只要调了就行，那或许还可以试试。但前提是 平常的压力之下，这些三方接口的处理速度必须要 > 生产速度，务必保证线程池里不会挤压任何任务。 让线程池 只用于应对 突发流量，保护三方接口不会被压垮（传说中的削峰）。

线程池其实就是一个内存级别的消息队列

你现在最好的情况 做横向扩展，在双 12 当天加机器，同时做一下网关层的限流

@Joker123456789 对顺序倒是没有要求，但是保证线程池里不会挤压任何任务，这个现实实现起来太难了，所以说线程池在这种场景下还是很难使用的。

@realrojeralone 暂时先不搞了 风险太大了 不如堆机器来的实在，瓶颈抛给下游业务

用线程池接收请求后发送到 MQ 队列慢慢消费, 根据流量水平扩展 MQ 和消费端