最近去南京一家公司面試時被問到的問題：如何設計一個高并發的http服務器？
從接觸這個問題開始，到現在為止，我個人的腦海里有若干種方案，很遺憾的是在面試的時候我只說出其中兩種。
但是我并不能確認我的這些方案是否正確與可行，是否可以高并發或者高效率。放在這里，希望大家多提意見。
為了使描述能夠更加清晰，我假設了一個高速公路收費站的模型：
1：一個用戶的請求就比作一輛汽車。
2：服務端的響應行為就比作收費站放閘、收錢、開閘等一系列動作（同步）。（最終目的是收錢）
方案一：
1：一個請求到來，開一個線程處理請求，處理完成，線程退出。
這里一個線程可以看做一個收費窗口，就好比收費站上來一輛汽車我開一個收費窗口，放行之后就關閉這個窗
口。如果所有窗口都在工作，那剩下的汽車就得處于等待狀態了。顯然，這樣工作的話，收費站的員工要累壞
了，一會兒開門進來一會兒關門出去，手酸。收費站的員工意見都很大。服務器中也一樣，一個服務端有一個
線程數的上限，不可能無限制創建線程。而且，雖然線程的創建和銷毀開銷不如進程來得大，但是頻繁創建和
銷毀的代價卻可能很巨大。
方案二：
1：開一個線程池。
2：一個請求來了之后，尋找一個“空閑”線程將其“喚醒”，處理請求之后，再讓其“休眠”。
這里的“喚醒”和“休眠”就好比開窗和關窗的動作，這比頻繁地開關門好多了。這對服務器來說，休眠狀態下
的線程不占用cpu時間片，這肯定是有利于其他線程的及時調度的。ok，現在收費員意見不大了，收費站外面排長
隊的汽車司機們的意見卻依舊：這么長一條高速路，俺們每次路過交那么多錢，結果個收費站才這么幾個窗口，害
得俺們每次都要排長隊等待。雖然現在這些收費的家伙時刻坐在里面，不用走出來走出去了，可是放閘、交錢、開閘
等動作太繁瑣和費時間了。
方案三：
1：開一個線程池。
2：一個請求來了，尋找一個“空閑”線程將其“喚醒”，處理請求之后，再讓其“休眠”。同時處理請求的過程采
用異步io的方式，大大縮短處理時間，可以讓線程及時“空閑”出來。
前面講過的方案中的處理請求的過程都是以同步io的方式來實現的。也就是收費站員工要放閘、收錢、開閘等一系列
動作。他必須要等到汽車司機把錢交了才能進入空閑狀態，可以處理下一個汽車的收費問題。這樣問題的關鍵就在于
收費員和司機的動作是否都足夠快（服務端和客戶端的溝通效率），即使兩者都很快，大部分時間還是被這一個過程
占用。其實收費站的主要目的就是收錢，而司機們就想快點達到終點。異步io的使用就類似于快速反應的實現，一個
收費窗口可以讓一輛車迅速通過，并且在后面安排其駛進一個帶有專業快速收費系統的地下車道，使其能夠照樣交錢
通過，并且使得后面等待的車可以繼續快速跟進。然后新的問題總會出現，收費站的窗口有限，而汽車在“春運”的
時候總會很多很多，即便使用了地下專業快速收費系統，收費窗口前的汽車依舊排起長龍。司機兄弟們脾氣都很火爆，
等久了，就會下車打架啦。
方案四：
1：開一個線程池。
2：將一個請求的處理過程細分成若干個細小的狀態。
3：一個請求到來之后迅速找到一個“空閑”線程，如果沒有，則找一個“工作”線程，使其當前正在處理的請求在
當前狀態下掛起，迅速響應新進來的請求，稍后再將最早掛起的狀態的請求恢復，如此循環，使得客戶端感覺仿佛沒有
等待的感覺。
收費站的領導目前正在為這個方案的實施大傷腦筋，這似乎是一個真正考驗他們管理能力的難題了，但是上峰的命令就
是汽車來了不能讓人家等，趕緊為司機“服務”。
說到這里，仿佛這四個方案都有其優缺點。同時我也想起以前聽到同事們將erlang，說其在分布式開發上很有優勢，但是
他們同時又強調高并發，不一定代表高性能。以前總不明白為什么既然要高并發了，卻沒有高性能呢？現在總算明白，
實際的需求總是在變化的，我們總要根據需求和實際情況做出最恰當的設計，必要的時候需要做出一些折中，我想這才是
一個優秀的程序員所必須具備的素質。