來源:http://blog.codingnow.com/2006/04/iocp_kqueue_epoll.html
設計 mmo 服務器，我聽過許多老生常談，說起處理大量連接時， select 是多么低效。我們應該換用 iocp (windows), kqueue(freebsd), 或是 epoll(linux) 。的確，處理大量的連接的讀寫，select 是夠低效的。因為 kernel 每次都要對 select 傳入的一組 socket 號做輪詢，那次在上海，以陳榕的說法講，這叫鬼子進村策略。一遍遍的詢問“鬼子進村了嗎？”，“鬼子進村了嗎？”... 大量的 cpu 時間都耗了進去。（更過分的是在 windows 上，還有個萬惡的 64 限制。）
使用 kqueue 這些，變成了派一些個人去站崗，鬼子來了就可以拿到通知，效率自然高了許多。不過最近我在反思，真的需要以這些為基礎搭建服務器嗎？
剛形成的一個思路是這樣的：
我們把處理外部連接和處理游戲邏輯分攤到兩個服務器上處理，為了后文容易表述，暫時不太嚴謹的把前者稱為連接服務器，后者叫做邏輯服務器。
連接服務器做的事情可以非常簡單，只是把多個連接上的數據匯集到一起。假設同時連接總數不超過 65536 個，我們只需要把每個連接上的數據包加上一個兩字節的數據頭就可以表識出來。這個連接服務器再通過單個連接和邏輯服務器通訊就夠了。
那么連接服務器盡可以用最高效的方式處理數據，它的邏輯卻很簡單，代碼量非常的小。而邏輯服務器只有一個外部連接，無論用什么方式處理都不會慢了。
進一步，我們可以把這個方法擴展開。假定我們邏輯以 10Hz 的頻率處理邏輯。我們就讓連接服務器以 10Hz 的脈沖把匯總的數據周期性的發送過去，先發一個長度信息再發數據包。即使一個脈沖沒有外部數據，也嚴格保證至少發一個 0 的長度信息。額外的，連接服務器還需要控制每個脈沖的數據總流量，不至于一次發送數據超過邏輯服務器處理的能力。
那么，邏輯服務器甚至可以用阻塞方式調用 recv 收取這些數據，連 select 也省了。至于數據真的是否會被接收方阻塞，就由連接服務器的邏輯保證了。
說到阻塞接收，我跟一個同事討論的時候，他嚴重擔心這個的可靠性，不希望因為意外把邏輯服務器掛在一個 system call 上。他列舉了許多可能發生的意外情況，不過我個人是不太擔心的，原因不想在這里多解釋。當然我這樣設計，主要不是為了節省一個 select 的調用，而是希望方便調試。（當然，如果事實證明這樣不可行，修改方案也很容易）
因為阻塞接收可以保證邏輯服務器的嚴格時序性，當我們把兩個服務器中的通訊記錄下來，以后可以用這些數據完全重現游戲邏輯的過程，無論怎么調試運行，都可以保證邏輯服務器的行為是可以完全重現的。即，每 0.1s 接受已知的數據包，然后處理它們。
這樣做，邏輯服務器對網絡層的代碼量的需求也大大減少了，可以更專心的構建邏輯。