關於多核的發展對網絡遊戲設計影響的一些思考

    早在幾年前，Herb sutter就發表了《免費午餐已經結束，軟件歷史性的向併發靠攏》一文，引起了業內很大的反應，現在雙核早已普及，09年應該是國內普及4核的一年。 Erlang這種老古董也因爲多核的發展而逐漸熱起來，網上關於普通程序員是否需要掌握多核編程技術也有很多爭論，不論大家觀點是否正確，至少多核相關技 術引起了開發人員的注意。
     我是做遊戲服務器開發的，公司的老遊戲的服務器機器配置一般是帶超線程的雙至強cpu，邏輯上是4個cpu（關於超線程的性能提升姑且不談），照理說，遊戲服務器早就應該是多線程的設計，但是據我瞭解，國內大部分的遊戲服務器遊戲邏輯部分都是單線程的，即存在所謂主線程的說法，單線程的設計是基於以 下幾個因素（以3000個玩家同時在線爲列）：
1：大概有20-30%的cpu被網絡IO佔用，網絡層很容易用多線程實現
2：可通過架構上的設計剝離數據訪問，IO等容易採用多線程實現的部分，剩下的佔用cpu密集的操作就是所謂的主線程
3：多線程的設計會導致開發週期延長，設計變得更加複雜，可維護性降低。
3：最關鍵的一點：多線程帶來的複雜性和bug數量，頻繁的宕機回檔是任何遊戲都不能忍受的。
4：再來分析一下以前的雙cpu服務器採用單線程的方式帶來的性能損失（超線程帶來的性能極爲有限，暫不做討論），粗略的來看，網絡IO部分可由2個 cpu平均分攤，再拋開一些鎖和緩存同步帶來的開銷及一些其他軟件（如監控，統計），損失大概30%-40%的性能，損失的性能和穩定性及開發週期等之間 權衡，當然選擇單線程的設計。

     再來看如果現在啓動一個新項目，對性能的考慮又該如何。首先做2個假設，1：項目週期爲2年，即2年後遊戲公測，或大規模內測。2：2年後服務器主流配置 爲16核，低端配置8核。如果仍採用單線程的服務器設計，以16核的cpu計算，損失的性能最少會達到800%，這個時候可能有人會說，我把所有的服務器 放到一臺機器上，甚至數據庫也放過來，這樣就能充分的利用到所有的cpu資源。不錯，我承認這樣基本上完全能利用cpu資源，但這不是遊戲的核心內容，以 前只能支持3000個玩家，10000個激活npc的服務器，現在仍然如此。硬件在發展，玩家的體驗需求也在發展，就像網絡的帶寬提升了100倍，我們仍 然只能看到斷斷續續的視頻一樣無法接受。說了這麼多，也無非是得出一個結論：多核的發展在遊戲開發當中必須引起重視。
那麼，又如何利用多核資源呢？我總結了一下，大概有以下幾種做法：
1：多進程設計，這是雲風走的路線
2：挑戰邏輯複雜性，設計良好的線程模型和數據結構
3：採用intel openmp 和 tbb 等技術

下面就以上幾種設計談談個人看法：
     多進程的設計很符合unix哲學，很kiss，難點在於進程的管理，通信，協調。優點是易於維護，調試，結構清晰。缺點是進程的管理麻煩，有一些效率損 失，最重要的一點是，多進程設計可能仍然無法有效的在多核cpu上提高效率，根據80-20法則，可能80%的cpu消耗在20%的進程內，如果根據功能 模塊劃分進程，即使設計良好的數據流水線，在20%的進程內也是需要做並行計算的。
     第2中做法風險太大，需要多年的遊戲設計經驗和很好很強大的設計能力。
     第3中做法比較折中，分析出佔用80%cpu的那20%的代碼，並行化。當然說起來比做起來容易，這種方式仍需要良好的數據結構的設計。舉個例子，同時對1000個怪物做尋路操作，這種只讀的操作是無需加鎖很容易並行化。

     結合以上幾種設計，我認爲最合適的做法是採用較粗粒度的進程，結合tbb等庫在cpu密集操作的進程內部做並行化 是一種相對較好的設計

寫的比較亂，有些地方不夠嚴謹，以上的想法只是提供一種思路，還並未在實踐中運用 ：）

ps：tbb中有pipeline框架，可在進程內部方便的提供流水線機制