IOCP , kqueue , epoll … 有多重要？

原文地址：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 接受已知的資料包，然後處理它們。

這樣做，邏輯伺服器對網路層的代碼量的需求也大大減少了，可以更專心的構建邏輯。