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