p/phoenix-framework-3/

[giscus[bot]]

p/phoenix-framework-3/

背景 从 0 到 1 设计业务并发框架系列： Phoenix 框架 小米商城产品站革新之路 Phoenix 框架 怎么组织设计一个框架 前两篇文章已经讲述了我设计框架的背景以及抽象设计的细节，今天讲一下并发框架最为关键的并发线程池的核心设计，主要讲一下在设计线程池划分遇到的问题以及最终我采用了哪种方式实现的。 将存在依赖关系的 Task 进行划分分组后，依次执行分组就可以拿到所有想要的结果，但是怎么划分线程池、设置线程池是面临的问题。 接下来，我将实际业务中的复杂度简化设计，将问题具象化呈现给大家。 # 方案：公用线程池 # 方案 最开始，我计划将分配的 Task 公用一个线程池，让 Task 去线程池竞争资源，如下图： 但是很快发现，单个线程池一旦请求数量上来，某个 Task 接口变慢就会导致整个接口成功率急速下降，直至不可用的状态。 为什么会出现这种情况呢？ # 效果 T1 时刻，第 1 波流量进来，之后率先执行 TaskA 或者 TaskB； TaskA 请求的快速递增，接口变得越来越慢； T2 时刻，还有两个 TaskA 并没有执行完毕，之后第二波流量进来： 第 1 波流量开始执行 TaskC 和 TaskD； 第 2 波流量进来，也有 TaskA 和 TaskB 获取到线程执行； T3 时刻，此时已经有 4 个 TaskA 还没有执行完，并且最开始的两个 TaskA 要面临着超时情况： 第 1 波流量执行的 TaskA 面临超时中断的情况； 第 2 波流量执行的 TaskA 也在运行状态中； 第 3 波流量进来，情况变得复杂，新的流量，有 TaskA 和 TaskB 进行执行； 此时第 1 波流量前两层运行完毕，开始执行 TaskE； 此时第 2 波流量的前一层运行完毕，开始执行 TaskC 和 TaskD； 之后按照 TaskA 始终慢的情况继续发展…….

https://blog.debuginn.com/p/phoenix-framework-3/