最近去南京一家公司面试时被问到的问题：如何设计一个高并发的http服务器？
从接触这个问题开始，到现在为止，我个人的脑海里有若干种方案，很遗憾的是在面试的时候我只说出其中两种。
但是我并不能确认我的这些方案是否正确与可行，是否可以高并发或者高效率。放在这里，希望大家多提意见。
为了使描述能够更加清晰，我假设了一个高速公路收费站的模型：
1：一个用户的请求就比作一辆汽车。
2：服务端的响应行为就比作收费站放闸、收钱、开闸等一系列动作（同步）。（最终目的是收钱）
方案一：
1：一个请求到来，开一个线程处理请求，处理完成，线程退出。
这里一个线程可以看做一个收费窗口，就好比收费站上来一辆汽车我开一个收费窗口，放行之后就关闭这个窗
口。如果所有窗口都在工作，那剩下的汽车就得处于等待状态了。显然，这样工作的话，收费站的员工要累坏
了，一会儿开门进来一会儿关门出去，手酸。收费站的员工意见都很大。服务器中也一样，一个服务端有一个
线程数的上限，不可能无限制创建线程。而且，虽然线程的创建和销毁开销不如进程来得大，但是频繁创建和
销毁的代价却可能很巨大。
方案二：
1：开一个线程池。
2：一个请求来了之后，寻找一个“空闲”线程将其“唤醒”，处理请求之后，再让其“休眠”。
这里的“唤醒”和“休眠”就好比开窗和关窗的动作，这比频繁地开关门好多了。这对服务器来说，休眠状态下
的线程不占用cpu时间片，这肯定是有利于其他线程的及时调度的。ok，现在收费员意见不大了，收费站外面排长
队的汽车司机们的意见却依旧：这么长一条高速路，俺们每次路过交那么多钱，结果个收费站才这么几个窗口，害
得俺们每次都要排长队等待。虽然现在这些收费的家伙时刻坐在里面，不用走出来走出去了，可是放闸、交钱、开闸
等动作太繁琐和费时间了。
方案三：
1：开一个线程池。
2：一个请求来了，寻找一个“空闲”线程将其“唤醒”，处理请求之后，再让其“休眠”。同时处理请求的过程采
用异步io的方式，大大缩短处理时间，可以让线程及时“空闲”出来。
前面讲过的方案中的处理请求的过程都是以同步io的方式来实现的。也就是收费站员工要放闸、收钱、开闸等一系列
动作。他必须要等到汽车司机把钱交了才能进入空闲状态，可以处理下一个汽车的收费问题。这样问题的关键就在于
收费员和司机的动作是否都足够快（服务端和客户端的沟通效率），即使两者都很快，大部分时间还是被这一个过程
占用。其实收费站的主要目的就是收钱，而司机们就想快点达到终点。异步io的使用就类似于快速反应的实现，一个
收费窗口可以让一辆车迅速通过，并且在后面安排其驶进一个带有专业快速收费系统的地下车道，使其能够照样交钱
通过，并且使得后面等待的车可以继续快速跟进。然后新的问题总会出现，收费站的窗口有限，而汽车在“春运”的
时候总会很多很多，即便使用了地下专业快速收费系统，收费窗口前的汽车依旧排起长龙。司机兄弟们脾气都很火爆，
等久了，就会下车打架啦。
方案四：
1：开一个线程池。
2：将一个请求的处理过程细分成若干个细小的状态。
3：一个请求到来之后迅速找到一个“空闲”线程，如果没有，则找一个“工作”线程，使其当前正在处理的请求在
当前状态下挂起，迅速响应新进来的请求，稍后再将最早挂起的状态的请求恢复，如此循环，使得客户端感觉仿佛没有
等待的感觉。
收费站的领导目前正在为这个方案的实施大伤脑筋，这似乎是一个真正考验他们管理能力的难题了，但是上峰的命令就
是汽车来了不能让人家等，赶紧为司机“服务”。
说到这里，仿佛这四个方案都有其优缺点。同时我也想起以前听到同事们将erlang，说其在分布式开发上很有优势，但是
他们同时又强调高并发，不一定代表高性能。以前总不明白为什么既然要高并发了，却没有高性能呢？现在总算明白，
实际的需求总是在变化的，我们总要根据需求和实际情况做出最恰当的设计，必要的时候需要做出一些折中，我想这才是
一个优秀的程序员所必须具备的素质。