在这种情况下，我们有 5 台客户端，都向应用程序发送请求。这个应用程序的访问入口是一个 Web 服务器，通过将服务分配给一个服务器 worker 池来充当负载均衡器，这些 worker 可以实现为进程、线程或者两者的结合。这些 worker 执行负载均衡器分配给他们的请求。你使用 Web 应用程序框架（例如 Flask 或 Django）编写的应用程序逻辑运行在这些 worker 中。

这种类型的方案对于有多个 CPU 的服务器比较好，因为你可以将 worker 的数量设置为 CPU 的数量，这样你就能均衡地利用你的处理器核心，而单个 Python 进程由于全局解释器锁（GIL）的限制无法实现这一点。

在缺点上，上面的示意图也清楚展示了这种方案的主要局限。我们有 5 个客户端，却只有 4 个 worker。如果这 5 个客户端在同一时间都发送请求，那么负载均衡器会将某一个客户端之外的所有请求发送到 worker 池，而剩下的请求不得不保留在一个队列中，等待有 worker 变得可用。因此，五分之四的请求会立即响应，而剩下的五分之一需要等一会儿。服务器优化的一个关键就在于选择适当数量的 worker 来防止或最小化给定预期负载的请求阻塞。

这种类型的服务器运行在单个进程中，通过循环控制。这个循环是一个非常有效率的任务管理器和调度器，创建任务来执行由客户端发送的请求。与长期存在的服务器 worker 不同，异步任务是由循环创建，用来处理某个特定的请求，当那个请求完成时，该任务也会被销毁。任何时候，一台异步服务器都会有上百或上千个活跃的任务，它们都在循环的管理下执行自己的工作。

你可能想知道异步任务之间的并行是如何实现的。这就是有趣的部分，因为一个异步应用程序通过唯一的协同多任务处理来实现这点。这意味着什么？当一个任务需要等待一个外部事件（例如，一个数据库服务器的响应）时，不会像一个同步的 worker 那样等待，而是会告诉循环，它需要等待什么，然后将控制权返回给它。循环就能够在这个任务被数据库阻塞的时候发现另外一个准备就绪的任务。最终，数据库将发送一个响应，而那时循环会认为第一个的任务已经准备好再次运行，并将尽快恢复它。