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