1、游戲的伺服器端是用C++開發還是用Java開發
那麼多游戲，誰知道
只能說多數的核心是C/C++的 ~~~~~
~~~~~~~~~
2、大型網路游戲服務端用什麼語言寫的？用什麼引擎或者框架
應該是用C語言寫的哈，大型的網路游戲都是一點點編程再糅合起來才會形成的，所以也有好多人說網游只不過是一堆數據而已。我學軟體有時候壓力挺大的就喜歡玩玩網游，玩的最多的就是火源計劃，因為裡面副本設計的特別精彩，能讓人完全投入其中，忘記不愉快的事兒，你有興趣也可以玩玩看的。
3、游戲伺服器開發為什麼很少使用c
C# 開發速度高 對於現代計算機來說,運行效率不是問題.. 最起碼比JAVA快得多得多
C++ 開發速度慢但是這是相對於熟練度來說的, 一個熟練使用C++的程序員開發一個東西也不慢 運行效率自然不用說..
很明顯,C#有個和JAVA一樣的特性.需要運行環境. 而C++則不需要..
這就絕定了. C#程序的傳播有局限性
綜合JAVA和C++的特點,我最終感覺C#是個非常矛盾的產物
論跨性, C#不及JAVA..(JAVA哪不能運行? C#呢,目前只能在WINDOWS)
論效率,C#不及C++.
所以覺得學習C#,實在不如去學習JAVA或者C++.
4、這樣就能架設個游戲伺服器？
想做奇跡SF還是其他網游 其實架設並不難 難的是裡面的設置 比如說後門啊什麼的 加殼的什麼的 如果你想學就要具備條件 資料庫 服務端 還有一台電腦 所謂伺服器 如果你找不到地址可以去這里下 http://www.qiannao.com/space/show/xiongxin36/%E4%B8%8A%E4%BC%A0%E5%88%86%E4%BA%AB/%E5%A5%87%E8%BF%B9%E6%9E%B6%E8%AE%BE%E8%A7%86%E9%A2%91%E6%95%99%E7%A8%8B.rar/.page 這是教程 這個是服務端地址http://www.qiannao.com/space/list/xiongxin36/%E4%B8%8A%E4%BC%A0%E5%88%86%E4%BA%AB/.page 不明白繼續追問
希望採納
5、寫游戲伺服器.ruby有沒有好的開源框架
不勝了解，因為我入行時這方面沒有什麼書籍可以看。我覺得學習網游伺服器開發可以從兩個方面下手： 基礎知識 架構知識 作為推薦，這里我主要還是推薦自己仔細研讀過的書，而我讀過的書中某些可能已經很老了，甚至內容已經過時了，因此，這只算是拋磚引玉，大家可以選擇類似的更新、更權威的書籍學習。 基礎知識主要包括： 語言。這里之所以拿出來說，是因為某些語言可能導致你使用完全不同的思路來設計伺服器。一般來說，C/C++、Java、C# 之類可以歸為一類，而 Go、Erlang 和他們區別很顯著。關於語言的經典書籍太多，這里就不說了。 網路。想了解協議底層實現，可以看《TCP/IP 詳解 卷2》。上層開發時，Windows 下可以看《Network Programming for Microsoft Windows》
6、golang有哪些不錯的游戲伺服器框架
<
7、端游，手游服務端常用的架構是什麼樣的
端游、手游服務端常用的架構是什麼樣的？
類型1：卡牌、跑酷等弱交互服務端卡牌跑酷類
因為交互弱，玩家和玩家之間不需要實時面對面PK，打一下對方的離線數據，計算下排行榜，買賣下道具即可，所以實現往往使用簡單的 HTTP伺服器：
登錄時可以使用非對稱加密（RSA, DH），伺服器根據客戶端uid，當前時間戳還有服務端私鑰，計算哈希得到的加密 key 並發送給客戶端。之後雙方都用 HTTP通信，並用那個key進行RC4加密。客戶端收到key和時間戳後保存在內存，用於之後通信，服務端不需要保存 key，因為每次都可以根據客戶端傳上來的 uid 和 時間戳 以及服務端自己的私鑰計算得到。用模仿 TLS的行為，來保證多次 HTTP請求間的客戶端身份，並通過時間戳保證同一人兩次登錄密鑰不同。
每局開始時，訪問一下，請求一下關卡數據，玩完了又提交一下，驗算一下是否合法，獲得什麼獎勵，資料庫用單台 MySQL或者 MongoDB即可，後端的 Redis做緩存（可選）。如果要實現通知，那麼讓客戶端定時15秒輪詢一下伺服器，如果有消息就取下來，如果沒消息可以逐步放長輪詢時間，比如30秒；如果有消息，就縮短輪詢時間到10秒，5秒，即便兩人聊天，延遲也能自適應。
此類伺服器用來實現一款三國類策略或者卡牌及酷跑的游戲已經綽綽有餘，這類游戲因為邏輯簡單，玩家之間交互不強，使用 HTTP來開發的話，開發速度快，調試只需要一個瀏覽器就可以把邏輯調試清楚了。
類型2：第一代游戲伺服器 1978
1978年，英國著名的財經學校University of Essex的學生 Roy Trubshaw編寫了世界上第一個MUD程序《MUD1》，在University of Essex於1980年接入 ARPANET之後加入了不少外部的玩家，甚至包括國外的玩家。《MUD1》程序的源代碼在 ARPANET共享之後出現了眾多的改編版本，至此MUD才在全世界廣泛流行起來。不斷完善的 MUD1的基礎上產生了開源的 MudOS（1991），成為眾多網游的鼻祖：
MUDOS採用 C語言開發，因為玩家和玩家之間有比較強的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服務所有玩家，所有玩家的請求都發到同一個線程去處理，主線程每隔1秒鍾更新一次所有對象（網路收發，更新對象狀態機，處理超時，刷新地圖，刷新NPC）。
游戲世界採用房間的形式組織起來，每個房間有東南西北四個方向可以移動到下一個房間，由於歐美最早的網游都是地牢迷宮形式的，因此場景的基本單位被成為 「房間」。MUDOS使用一門稱為LPC的腳本語言來描述整個世界（包括房間拓撲，配置，NPC，以及各種劇情）。游戲裡面的高級玩家（巫師），可以不斷的通過修改腳本來為游戲添加房間以及增加劇情。早年 MUD1上線時只有17個房間，Roy Trubshaw畢業以後交給他的師弟 Richard Battle，在 Richard Battle手上，不斷的添加各種玩法到一百多個房間，終於讓 MUD發揚光大。
用戶使用 Telnet之類的客戶端用 Tcp協議連接到 MUDOS上，使用純文字進行游戲，每條指令用回車進行分割。比如 1995年國內第一款 MUD游戲《俠客行》，你敲入：」go east」，游戲就會提示你：「後花園 - 這里是歸雲庄的後花園，種滿了花草，幾個庄丁正在澆花。此地乃是含羞草生長之地。這里唯一的出口是 north。這里有：花待 阿牧（A mu），還有二位庄丁（Zhuang Ding）」，然後你繼續用文字操作，查看阿牧的信息：「look a mu」，系統提示：「花待 阿牧（A mu）他是陸乘風的弟子，受命在此看管含羞草。他看起來三十多歲，生得眉清目秀，端正大方，一表人才。他的武藝看上去【不是很高】，出手似乎【極輕】」。然後你可以選擇擊敗他獲得含羞草，但是你吃了含羞草卻又可能會中毒死亡。在早期網上資源貧乏的時候，這樣的游戲有很強的代入感。
用戶數據保存在文件中，每個用戶登錄時，從文本文件里把用戶的數據全部載入進來，操作全部在內存裡面進行，無需馬上刷回磁碟。用戶退出了，或者每隔5分鍾檢查到數據改動了，都會保存會磁碟。這樣的系統在當時每台伺服器承載個4000人同時游戲，不是特別大的問題。從1991年的 MUDOS發布後，全球各地都在為他改進，擴充，退出新版本，隨著 Windows圖形機能的增強。1997游戲《UO》在 MUDOS的基礎上為角色增加的x,y坐標，為每個房間增加了地圖，並且為每個角色增加了動畫，形成了第一代的圖形網路游戲。
因為游戲內容基本可以通過 LPC腳本進行定製，所以MUDOS也成為名副其實的第一款服務端引擎，引擎一次性開發出來，然後製作不同游戲內容。後續國內的《萬王之王》等游戲，很多都是跟《UO》一樣，直接在 MUDOS上進行二次開發，加入房間的地圖還有角色的坐標等要素，該架構一直為國內的第一代 MMORPG提供了穩固的支持，直到 2003年，還有游戲基於 MUDOS開發。雖然後面圖形化增加了很多東西，但是這些MMORPG後端的本質還是 MUDOS。隨著游戲內容的越來越復雜，架構變得越來越吃不消了，各種負載問題慢慢浮上水面，於是有了我們的第二代游戲伺服器。
類型3：第二代游戲伺服器 2003
2000年後，網游已經脫離最初的文字MUD，進入全面圖形化年代。最先承受不住的其實是很多小文件，用戶上下線，頻繁的讀取寫入用戶數據，導致負載越來越大。隨著在線人數的增加和游戲數據的增加，伺服器變得不抗重負。同時早期 EXT磁碟分區比較脆弱，稍微停電，容易發生大面積數據丟失。因此第一步就是拆分文件存儲到資料庫去。
此時游戲服務端已經脫離陳舊的 MUDOS體系，各個公司在參考 MUDOS結構的情況下，開始自己用 C在重新開發自己的游戲服務端。並且腳本也拋棄了 LPC，採用擴展性更好的 Python或者 Lua來代替。由於主邏輯使用單線程模型，隨著游戲內容的增加，傳統單伺服器的結構進一步成為瓶頸。於是有人開始拆分游戲世界，變為下面的模型：
游戲伺服器壓力拆分後得意緩解，但是兩台游戲伺服器同時訪問資料庫，大量重復訪問，大量數據交換，使得資料庫成為下一個瓶頸。於是形成了資料庫前端代理（DB Proxy），游戲伺服器不直接訪問資料庫而是訪問代理，再有代理訪問資料庫，同時提供內存級別的cache。早年 MySQL4之前沒有提供存儲過程，這個前端代理一般和 MySQL跑在同一台上，它轉化游戲伺服器發過來的高級數據操作指令，拆分成具體的資料庫操作，一定程度上代替了存儲過程：
但是這樣的結構並沒有持續太長時間，因為玩家切換場景經常要切換連接，中間的狀態容易錯亂。而且游戲伺服器多了以後，相互之間數據交互又會變得比較麻煩，於是人們拆分了網路功能，獨立出一個網關服務 Gate（有的地方叫 Session，有的地方叫 LinkSvr之類的，名字不同而已）：
把網路功能單獨提取出來，讓用戶統一去連接一個網關伺服器，再有網關伺服器轉發數據到後端游戲伺服器。而游戲伺服器之間數據交換也統一連接到網管進行交換。這樣類型的伺服器基本能穩定的為玩家提供游戲服務，一台網關服務1-2萬人，後面的游戲伺服器每台服務5k-1w，依游戲類型和復雜度不同而已，圖中隱藏了很多不重要的伺服器，如登錄和管理。這是目前應用最廣的一個模型，到今天任然很多新項目會才用這樣的結構來搭建。
人都是有慣性的，按照先前的經驗，似乎把 MUDOS拆分的越開性能越好。於是大家繼續想，網關可以拆分呀，基礎服務如聊天交易，可以拆分呀，還可以提供web介面，資料庫可以拆分呀，於是有了下面的模型：
這樣的模型好用么？確實有成功游戲使用類似這樣的架構，並且發揮了它的性能優勢，比如一些大型 MMORPG。但是有兩個挑戰：每增加一級伺服器，狀態機復雜度可能會翻倍，導致研發和找bug的成本上升；並且對開發組挑戰比較大，一旦項目時間吃緊，開發人員經驗不足，很容易弄掛。
比如我見過某上海一線游戲公司的一個 RPG上來就要上這樣的架構，我看了下他們團隊成員的經驗，問了下他們的上線日期，勸他們用前面稍微簡單一點的模型。人家自信得很，認為有成功項目是這么做的，他們也要這么做，自己很想實現一套。於是他們義無反顧的開始編碼，項目做了一年多，然後，就沒有然後了。
現今在游戲成功率不高的情況下，一開始上一套比較復雜的架構需要考慮投資回報率，比如你的游戲上線半年內 PCU會去到多少？如果一個 APRG游戲，每組伺服器5千人都到不了的話，那麼選擇一套更為貼近實際情況的結構更為經濟。即使後面你的項目真的超過5千人朝著1萬人目標奔的話，相信那個時候你的項目已經掙大錢了 ，你數著錢加著班去逐步迭代，一次次拆分它，相信心裡也是樂開花的。
上面這些類型基本都是從拆分 MUDOS開始，將 MUDOS中的各個部件從單機一步步拆成分布式。雖然今天任然很多新項目在用上面某一種類似的結構，或者自己又做了其他熱點模塊的拆分。因為他們本質上都是對 MUDOS的分解，故將他們歸納為第二代游戲伺服器。
類型4：第三代游戲伺服器
2007從魔獸世界開始無縫世界地圖已經深入人心，比較以往游戲玩家走個幾步還需要切換場景，每次切換就要等待 LOADING個幾十秒是一件十分破壞游戲體驗的事情。於是對於 2005年以後的大型 MMORPG來說，無縫地圖已成為一個標准配置。比較以往按照地圖來切割游戲而言，無縫世界並不存在一塊地圖上面的人有且只由一台伺服器處理了：
每台 Node伺服器用來管理一塊地圖區域，由 NodeMaster（NM）來為他們提供總體管理。更高層次的 World則提供大陸級別的管理服務。這里省略若干細節伺服器，比如傳統資料庫前端，登錄伺服器，日誌和監控等，統統用 ADMIN概括。在這樣的結構下，玩家從一塊區域走向另外一塊區域需要簡單處理一下：
玩家1完全由節點A控制，玩家3完全由節點B控制。而處在兩個節點邊緣的2號玩家，則同時由A和B提供服務。玩家2從A移動到B的過程中，會同時向A請求左邊的情況，並向B請求右邊的情況。但是此時玩家2還是屬於A管理。直到玩家2徹底離開AB邊界很遠，才徹底交由B管理。按照這樣的邏輯將世界地圖分割為一塊一塊的區域，交由不同的 Node去管理。
對於一個 Node所負責的區域，地理上沒必要連接在一起，比如大陸的四周邊緣部分和高山部分的區塊人比較少，可以統一交給一個Node去管理，而這些區塊在地理上並沒有聯系在一起的必要性。一個 Node到底管理哪些區塊，可以根據游戲實時運行的負載情況，定時維護的時候進行更改 NodeMaster 上面的配置。於是碰到第一個問題是很多 Node伺服器需要和玩家進行通信，需要問管理伺服器特定UID為多少的玩家到底在哪台 Gate上，以前按場景切割的伺服器這個問題不大，問了一次以後就可以緩存起來了，但是現在伺服器種類增加不少，玩家又會飄來飄去，按UID查找玩家比較麻煩；另外一方面 GATE需要動態根據坐標計算和哪些 Node通信，導致邏輯越來越厚，於是把：「用戶對象」從負責連接管理的 GATE中切割出來勢在必行於是有了下面的模型：
網關伺服器再次退回到精簡的網路轉發功能，而用戶邏輯則由按照 UID劃分的 OBJ伺服器來承擔，GATE是按照網路接入時的負載來分布，而 OBJ則是按照資源的編號（UID）來分布，這樣和一個用戶通信直接根據 UID計算出 OBJ伺服器編號發送數據即可。而新獨立出來的 OBJ則提供了更多高層次的服務：
對象移動：管理具體玩家在不同的 Node所管轄的區域之間的移動，並同需要的 Node進行溝通。
數據廣播：Node可以給每個用戶設置若干 TAG，然後通知 Object Master 按照TAG廣播。
對象消息：通用消息推送，給某個用戶發送數據，直接告訴 OBJ，不需要直接和 GATE打交道。
好友聊天：角色之間聊天直接走 OBJ/OBJ MASTER。整個伺服器主體分為三層以後，NODE專注場景，OBJ專注玩家對象，
GATE專注網路。這樣的模型在無縫場景伺服器中得到廣泛的應用。但是隨著時間的推移，負載問題也越來越明顯，做個活動，遠來不活躍的區域變得十分活躍，靠每周維護來調整還是比較笨重的，於是有了動態負載均衡。動態負載均衡有兩種方法，第一種是按照負載，由 Node Master 定時動態移動修改一下各個 Node的邊界，而不同的玩家對象按照先前的方法從一台 Node上遷移到另外一台 Node上：
圖11 動態負載均衡
Node Master定時查找地圖上的熱點區域，計算新的場景切割方式，然後告訴其他伺服器開始調整，具體處理方式還是和上面對象跨越邊界移動的方法一樣。但是上面這種方式實現相對復雜一些，於是人們設計出了更為簡單直接的一種新方法：
圖12 基於網格的動態負載均衡
於網格的動態負載均衡還是將地圖按照標准尺寸均勻切割成靜態的網格，每個格子由一個具體的Node負責，但是根據負載情況，能夠實時的遷移到其他 Node上。在遷移分為三個階段：准備，切換，完成。三個狀態由Node Master負責維護。准備階段新的 Node開始同步老 Node上面該網格的數據，完成後告訴NM；NM確認OK後同時通知新舊 Node完成切換。完成切換後，如果 Obj伺服器還在和老的 Node進行通信，老的 Node將會對它進行糾正，得到糾正的 OBJ將修正自己的狀態，和新的 Node進行通信。
很多無縫動態負載均衡的服務端宣稱自己支持無限的人數，但不意味著 MMORPG游戲的人數上限真的可以無限擴充，因為這樣的體系會受制於網路帶寬和客戶端性能。帶寬決定了同一個區域最大廣播上限，而客戶端性能決定了同一個屏幕到底可以繪制多少個角色。
從無縫地圖引入了分布式對象模型開始，已經完全脫離 MUDOS體系，成為一種新的服務端模型。又由於動態負載均衡的引入，讓無縫伺服器如虎添翼，容納著超過上一代游戲伺服器數倍的人數上限，並提供了更好的游戲體驗，我們稱其為第三代游戲服務端架構。網游以大型多人角色扮演為開端，RPG網游在相當長的時間里一度占據90%以上，使得基於 MMORPG的服務端架構得到了蓬勃的發展，然而隨著玩家對RPG的疲憊，各種非MMORPG游戲如雨後春筍般的出現在人們眼前，受到市場的歡迎。
類型5：戰網游戲伺服器
經典戰網服務端和 RPG游戲有兩個區別：RPG是分區分服的，北京區的用戶和廣州區的用戶老死不相往來。而戰網，雖然每局游戲一般都是 8人以內，但全國只有一套伺服器，所有的玩家都可以在一起游戲，而玩家和玩家之使用 P2P的方式連接在一起，組成一局游戲：
玩家通過 Match Making 伺服器使用：創建、加入、自動匹配、邀請 等方式組成一局游戲。伺服器會選擇一個人做 Host，其他人 P2P連接到做主的玩家上來。STUN是幫助玩家之間建立 P2P的牽引伺服器，而由於 P2P聯通情況大概只有 75%，實在聯不通的玩家會通過 Forward進行轉發。
大量的連接對戰，體育競技游戲採用類似的結構。P2P有網狀模型（所有玩家互相連接），和星狀模型（所有玩家連接一個主玩家）。復雜的游戲狀態在網狀模型下難以形成一致，因此星狀P2P模型經受住了歷史的考驗。除去游戲數據，支持語音的戰網系統也會將所有人的語音數據發送到做主的那個玩家機器上，通過混音去重再編碼的方式返回給所有用戶。
戰網類游戲，以競技、體育、動作等類型的游戲為主，較慢節奏的 RPG（包括ARPG）有本質上的區別，而激烈的游戲過程必然帶來到較 RPG復雜的多的同步策略，這樣的同步機制往往帶來的是很多游戲結果由客戶端直接計算得出，那在到處都是破解的今天，如何保證游戲結果的公正呢？
主要方法就是投票法，所有客戶端都會獨立計算，然後傳遞給伺服器。如果結果相同就更新記錄，如果結果不一致，會採取類似投票的方式確定最終結果。同時記錄本劇游戲的所有輸入，在可能的情況下，找另外閑散的游戲客戶端驗算整局游戲是否為該結果。並且記錄經常有作弊嫌疑的用戶，供運營人員封號時參考。
類型7：休閑游戲伺服器
休閑游戲同戰網伺服器類似，都是全區架構，不同的是有房間伺服器，還有具體的游戲伺服器，游戲主體不再以玩家 P2P進行，而是連接到專門的游戲伺服器處理：
和戰網一樣的全區架構，用戶數據不能象分區的 RPG那樣一次性load到內存，然後在內存裡面直接修改。全區架構下，為了應對一個用戶同時玩幾個游戲，用戶數據需要區分基本數據和不同的游戲數據，而游戲數據又需要區分積分數據、和文檔數據。勝平負之類的積分可以直接提交增量修改，而更為普遍的文檔類數據則需要提供讀寫令牌，寫令牌只有一塊，讀令牌有很多塊。同帳號同一個游戲同時在兩台電腦上玩時，最先開始的那個游戲獲得寫令牌，可以操作任意的用戶數據。而後開始的那個游戲除了可以提交勝平負積分的增量改變外，對用戶數據採用只讀的方式，保證游戲能運行下去，但是會提示用戶，游戲數據鎖定。
類型8：現代動作類網游
從早期的韓國動作游戲開始，傳統的戰網動作類游戲和 RPG游戲開始嘗試融合。單純的動作游戲玩家容易疲倦，留存也沒有 RPG那麼高；而單純 RPG戰斗卻又慢節奏的乏味，無法滿足很多玩家激烈對抗的期望，於是二者開始融合成為新一代的：動作 + 城鎮 模式。玩家在城鎮中聚集，然後以開副本的方式幾個人出去以動作游戲的玩法來完成各種 RPG任務。本質就是一套 RPG服務端+副本服務端。由於每次副本時人物可以控制在8人以內，因此可以獲得更為實時的游戲體驗，讓玩家玩的更加爽快。
說了那麼多的游戲伺服器類型，其實也差不多了，剩下的類型大家拼湊一下其實也就是這個樣子而已。
8、c語言有網路編程有沒有人使用c做游戲伺服器
目前通用的編程語言有兩種形式：匯編語言和高級語言。
匯編語言的實質和機器語言是相同的，都是直接對硬體操作，只不過指令採用了英文縮寫的標識符，更容易識別和記憶。它同樣需要編程者將每一步具體的操作用命令的形式寫出來。匯編程序通常由三部分組成：指令、偽指令和宏指令。匯編程序的每一句指令只能對應實際操作過程中的一個很細微的動作，例如移動、自增，因此匯編源程序一般比較冗長、復雜、容易出錯，而且使用匯編語言編程需要有更多的計算機專業知識，但匯編語言的優點也是顯而易見的，用匯編語言所能完成的操作不是一般高級語言所能實現的，而且源程序經匯編生成的可執行文件不僅比較小，而且執行速度很快。
高級語言是目前絕大多數編程者的選擇。和匯編語言相比，它不但將許多相關的機器指令合成為單條指令，並且去掉了與具體操作有關但與完成工作無關的細節，例如使用堆棧、寄存器等，這樣就大大簡化了程序中的指令。同時，由於省略了很多細節，編程者也就不需要有太多的專業知識。
高級語言主要是相對於匯編語言而言，它並不是特指某一種具體的語言，而是包括了很多編程語言，如目前流行的VB、VC、FoxPro、Delphi等，這些語言的語法、命令格式都各不相同。
高級語言所編制的程序不能直接被計算機識別，必須經過轉換才能被執行，按轉換方式可將它們分為兩類:
解釋類：執行方式類似於我們日常生活中的「同聲翻譯」，應用程序源代碼一邊由相應語言的解釋器「翻譯」成目標代碼(機器語言)，一邊執行，因此效率比較低，而且不能生成可獨立執行的可執行文件，應用程序不能脫離其解釋器，但這種方式比較靈活，可以動態地調整、修改應用程序。
編譯類：編譯是指在應用源程序執行之前，就將程序源代碼「翻譯」成目標代碼(機器語言)，因此其目標程序可以脫離其語言環境獨立執行，使用比較方便、效率較高。但應用程序一旦需要修改，必須先修改源代碼，再重新編譯生成新的目標文件(＊ .OBJ)才能執行，只有目標文件而沒有源代碼，修改很不方便。現在大多數的編程語言都是編譯型的，例如Visual C＋＋、Visual Foxpro、Delphi等。
9、是否有人對mmorpg游戲伺服器框架結構有興趣
服務程序最為關鍵的設計是並發服務模型，當前有以下幾種典型的模型：
- 單進程服務，使用非阻塞IO
使用一個進程服務多個客戶，通常與客戶通信的套接字設置為非阻塞的，阻塞只發生在select()、poll()、epoll_wait()等系統調用上面。這是一種行之有效的單進程狀態機式服務方式，已被廣泛採用。
缺點是它無法利用SMP(對稱多處理器)的優勢，除非啟動多個進程。此外，它嘗試就緒的IO文件描述符後，立即從系統調用返回，這會導致大量的系統調用發生，尤其是在較慢的位元組傳輸時。
select()本身的實現也是有局限的：能打開的文件描述符最多不能超過FD_SETSIZE，很容易耗盡；每次從select()返回的描述符組中掃描就緒的描述符需要時間，如果就緒的描述符在末尾時更是如此（epoll特別徹底修復了這個問題）。
- 多進程服務，使用阻塞IO
也稱作 accept/fork 模型，每當有客戶連線時產生一個新的進程為之服務。這種方式有時是必要的，比如可以通過操作系統獲得良好的內存保護，可以以不同的用戶身份運行程序，可以讓服務運行在不同的目錄下面。但是它的缺點也很明顯：進程比較占資源，進程切換開銷太大，共享某些信息比較麻煩。Apache 1.3就使用了這種模型，MaxClients數很容易就可以達到。
- 多線程服務，使用阻塞IO
也稱之 accept/pthread_create模型，有新客戶來時創建一個服務線程而不是服務進程。這解決了多進程服務的一些問題，比如它佔用資源少，信息共享方便。但是麻煩在於線程仍有可能消耗光，線程切換也需要開銷。
- 混合服務方式
所謂的混合服務方式，以打破服務方和客戶方之間嚴格的1:1關系。基本做法是：
新客戶到來時創建新的工作線程，當該工作線程檢測到網路IO會有延遲時停止處理過程，返回給Server一個延遲處理狀態，同時告訴 Server被延遲的文件描述符，延遲超時時間。Server會在合適的時候返回工作線程繼續處理。注意這里的工作線程不是通過 pthread_create()創建的，而是被包裝在專門用於處理延遲工作的函數里。
這里還有一個問題，工作線程如何檢測網路IO會有延遲？方法有很多，比如設置較短的超時時間調用poll()，或者甚至使用非阻塞IO。如果是套接字，可以設置SO_RCVTIMEO和SO_SNDTIMEO選項，這樣更有效率。
除了延遲線程，Server還應提供了未完成線程的支持。
如有有特別耗費時間的操作，你可以在完成部分工作後停止處理，返回給Server一個未完成狀態。這樣Server會檢查工作隊列是否有別的線程，如果有則讓它們運行，否則讓該工作線程繼續處理，這可以防止某些線程挨餓。
典型的一個混合服務模型開源實現ServerKit
Serverkit的這些線程支持功能可簡化我們的服務程序設計，效率上應該也是有保證的。
2. 隊列(queue)
ServerKit提供的隊列是一個單向鏈表，隊列的存取是原子操作，如果只有一個執行單元建議不要用，因為原子操作的開銷較大。
3. 堆(heap)
malloc()分配內存有一定的局限，比如在多線程的環境里，需要序列化內存分配操作。ServerKit提供的堆管理函數，可快速分配內存，可有效減少分配內存的序列化操作，堆的大小可動態增長，堆有引用計數，這些特徵比較適合多線程環境。目前ServerKit堆的最大局限是分配單元必須是固定大小。
4. 日誌記錄
日誌被保存在隊列，有一個專門的線程處理隊列中的日誌記錄：它或者調用syslog()寫進系統日誌，或者通過UDP直接寫到遠程機器。後者更有效。
5. 讀寫鎖
GNU libc也在pthreads庫里實現了讀寫鎖，如果定義了__USE_UNIX98就可以使用。不過ServerKit還提供了讀寫鎖互相轉換的函數，這使得鎖的應用更為彈性。比如擁有讀鎖的若干個線程對同一個hash表進行檢索，其中一個線程檢索到了數據，此時需要修改它，一種辦法是獲取寫鎖，但這會導致釋放讀鎖和獲取寫鎖之間存在時間窗，另一種辦法是使用ServerKit提供的函數把讀鎖轉換成寫鎖，無疑這種方式更有效率。
除了以上這些功能，ServerKit還提供了資料庫連接池的管理（當前只支持MySQL）和序列化（Sequences），如感興趣可參見相關的API文檔。
二、ServerKit服務模塊編寫
ServerKit由3部分組成：server程序，負責載入服務模塊、解析配置文件、建立資料庫連接池；libserver，動態鏈接庫，提供所有功能的庫支持，包括server本身也是調用這個庫寫的；API，編程介面，你編寫的服務模塊和ServerKit框架進行對話的介面。
ServerKit需要libConfuse解析配置文件，所以出了安裝ServerKit，還需要安裝libConfuse。關於libConfuse可參考
下面我們看一個簡單的服務模塊FOO：
#include
#include
static long int sleep_ration;
static int FOO_construct()
{
fprintf(stderr, "FOO_construct\n");
return 1;
}
static int FOO_prestart(cfg_t *configuration)
{
fprintf(stderr, "FOO_prestart\n");
return 1;
}
static void * FOO_operator(void *foobar)
{
fprintf(stderr, "FOO_operator\n");
for(;;) sleep(sleep_ration);
return NULL;
}
static void FOO_report(void)
{
fprintf(stderr, "FOO_report\n");
}
static cfg_opt_t FOO_config[] = {
CFG_SIMPLE_INT("sleep_ration", &sleep_ration),
CFG_END()
};
static char *FOO_authors[] = {"Vito Caputo ", NULL};
SERVER_MODULE(FOO,0,0,1,"Example mole that does nothing but sleep")按以下方法編譯：
$ gcc -c -fPIC -pthread -D_REENTRANT -g FOO.c
$ gcc -shared -lserver -lconfuse -lpthread -g -e __server_mole_main -o FOO.so FOO.o
-e選項指定程序運行入口，這使得你可以直接在命令行敲 ./FOO.so 運行模塊。
server程序根據環境變數SERVER_PERSONALITY_PATH定位主目錄，並查找主目錄下的c11n作為配置文件，動態載入的模塊需放在主目錄下的moles目錄。
$ export SERVER_PERSONALITY_PATH=`pwd`
$ mkdir moles
$ cp FOO.so moles
$ vi c11n
c11n的內容：
identity = "any_id"
FOO {
sleep_ration = 1;
}
identity標識server實例，用ps可看到程序名稱形如server.identity，本例為server.any_id。
執行server啟動服務程序。
三、ServerKit其他功能缺陷
缺乏daemon模式；
只能運行在Linux box；
DB pool只支持MySQL；
Heap管理內存的功力有限
10、想學C++游戲伺服器編程，應該學點什麼呢？
學習Linux網路編程、TCP/IP通訊協議、多線程編程再加資料庫，如果伺服器用C++的話，這方便必須要精通。其它游戲、繪圖的演算法有所涉獵就行。