代理服务器（5）---从并发回到迭代

上篇讲到并发。而且是在自己的代码里边并发，着实有点复杂。最关键的问题是，一台服务器，他的CPU核数是有限的。搞太多的并发，对调度是有消耗的。因此我们不能过度依赖并发。网络程序，排队是必不可免的。如何提高单核的处理能力才是关键。比如，系统可能支持一千个并发请求。这一千个并发请求会均摊到10个并发处理单元（进程或线程），每个单元排队处理100个。这种模式要比直接上1000个线程，每个线程处理一个要高效的多。至少从系统的资源消耗来讲，减少了990个线程的资源开销，减少了线程的调度开销。

因此，我们又回到了起点，如何设计一个优秀的迭代式服务器。如何在迭代的基础上加上必要的并发。

这样的问题，基本上有两种解决方案。

1）多进程/线程并发，每个进程/线程内部迭代处理。各个进程/线程的地位是等同的。

2）生产者/消费者模型。生产者负责处理用户的I/O请求，是迭代处理的。消费者是一个进程/线程池，用来处理请求队列。

第一种情况适用于计算量较小的I/O问题。如我们这里讨论的代理服务器。他对系统消耗基本上都在IO上。对CPU压力较小。

第二种情况适用于需要计算（消耗CPU）的场景。生产者通常占用的线程/进程数量要远小于消费者。

我们这里，不接受第二种模型的实现。大家有兴趣可以自己去尝试。

回到具体问题，我们如何才能让代理服务器不阻塞在处理具体的HTTP请求呢？

在我们回答这个问题前，假设代理服务器处理具体的HTTP请求不消耗任何时间。那么，来自不同用户的代理请求会不会被代理服务器阻塞？答案是否定的。这要归功于我们使用的AnyEvent框架。这个框架实际上是一个反应器(Reactor)，或者用别的名字，可以称为事件派发器。整个系统是事件驱动的，代理服务器仅仅在没有事件发生时会阻塞。一旦有用户接入或者有用户数据上传过来，代理服务器就会触发相应的动作。

既然有这么高级的东西，我们的代理服务器在访问远程服务器的时候也是可以利用这个反应器的。我们可以注册类似的回调函数，当远程服务器可写时，发送HTTP请求，当远程服务器返回数据时，把数据写到客户端。

这样的一个单进程服务，吞吐量还是很高的。如果觉得一个进程不够用。我们可以在整个业务的再上一层加上一个负载均衡的装置，从而可以做到多进程（或者分布式）处理。

具体的代码我们会在下一篇介绍。