遊戲伺服器架構和web伺服器架構的區別？
很多頁游（手游）的後端也是用PHP，java直接架構，那這些頁游（手游）的後端架構和一般網站的架構區別是什麼？
以下幾個角度闡述：
1-技術有什麼區別
2-思維有什麼區別
3-架構的側重點有什麼區別
4-本質有無區別
以前做WEB伺服器，最近在研究遊戲伺服器，試著回答一下吧。不對的地方請各位斧正一下。
1-技術有什麼區別首先通信上目前的主流是HTTP協議和SOCKET這兩種(HTML5提供了一種新的協議，WebScoket，對此了解並不多，因此不做評論，以免誤導)。HTTP連接最顯著的特點是客戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱為「一次連接」。
（註：在HTTP 1.1中則可以在一次連接中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。）
Socket又稱"套接字"，應用程序通常通過"套接字"向網路發出請求或者應答網路請求。
以J2SDK-1.3為例，Socket和ServerSocket類庫位於http://java.net包中。ServerSocket用於伺服器端，Socket是建立網路連接時使用的。在連接成功時，應用程序兩端都會產生一個Socket實例，操作這個實例，完成所需的會話。對於一個網路連接來說，套接字是平等的，並沒有差別，不因為在伺服器端或在客戶端而產生不同級別。不管是Socket還是ServerSocket它們的工作都是通過SocketImpl類及其子類完成的。（摘自百科）
在WEB伺服器中，一般情況是只需要使用HTTP協議的。因為它不太需要去與瀏覽器進行主動推送，只需要響應瀏覽器的訪問就足夠了
而在遊戲伺服器，這樣的連接方式肯定是不夠用的。很多時候遊戲伺服器是需要主動推送消息，如系統廣播。2-思維有什麼區別
WEB伺服器並不需要高頻即時通訊，對響應速度要求不高。而遊戲伺服器，大多數是需要很及時的響應速度（暫不討論弱聯網遊戲）。如DOTA，這種競技類型的遊戲，1秒就能發生很多事。因此，在思考方向上，WEB伺服器應該考慮是的多平台的兼容，大量用戶訪問的高並發。
而遊戲伺服器應該考慮的是高頻通訊，高並發。3-架構的側重點有什麼區別
在架構上面，一般訪問量不是很大的網站是只有一台伺服器的，訪問量高的才會進行分散式設計或者集群設計。
而大部分遊戲伺服器都是需要分散式設計的。在現有的網路遊戲伺服器端架構中，多是以功能和場景來劃分伺服器結構的。具體的劃分是根據項目的需求進行的，並沒有一個十分通用的架構。
以上是比較常見的結構，客戶端登錄的時候，連接GateServer，然後由GateServer去連接LoginServer進行登錄。登錄後通過CenterServer轉發到GameServer（GameServer即是伺服器大區）。
而其中的DCServer，主要的功能是緩存玩家角色數據，保證角色數據能快速的讀取和保存。LogServer便是保存日誌的了。4-本質有無區別
本質上，兩者並無區別，只是需求不同，側重點不同罷了。大致就是這樣，有錯誤地方希望能指出來。
=========================================================
一年過去了。感覺，我又強了幾分。再來補充點好了，也當作是一個自我總結。個人感覺上，遊戲和web伺服器之間最大的區別就是業務上的不同。遊戲的業務大多數都是很複雜的情況，而且對即時性要求比較高（部分弱聯網遊戲對即時性要求不高，拋開業務甚至可以直接照搬web伺服器架構）。
數據的同步：
在大型遊戲上，有一個很重要的話題便是數據的同步。任何即時操作的遊戲都繞不開這個話題，數據的同步直接影響著用戶的體驗。我們既要保證數據的一致性，又要保證玩家遊戲的流暢性。這其中是需要做許多取捨的。/*目前數據的同步主要有兩種，幀同步與狀態同步（各有優劣，應用環境不同，在此不展開）。這兩種同步都只是一個大的方向，並不是一個完善的解決方案。比如幀同步在弱網路環境下是否需要冗餘保證數據完整性，比如是使用tcp還是udp，亦或者是兩者混合使用。這些都沒有一個確切的答案，都處於摸索之中。*/而web伺服器並無此種糾結，它們的數據都在伺服器，並不需要用戶與用戶之間的強交互。數據同步的延遲也就不那麼難以忍受了。集群與分散式：
當一個網站訪問人數很龐大的情況下，單獨去提升一台物理機配置能夠帶來的性能提升會因為邊際效應逐漸減小。這時候就需要考慮使用集群了。集群有三種，高可用集群， 負載均衡集群，科學計算集群。其中最常見的便是負載均衡。很多情況下，集群之間是不需要互相交互的，數據都在單個伺服器上進行處理，也就沒了同步的問題（相比遊戲伺服器要簡單了多）。相對於遊戲的難點就在於遊戲我們可以通過分區分服甚至分頻道等方式來減小伺服器負載壓力。而網站是無法這樣讓用戶分區之類的操作。甚至是需要，全國各地乃至全球各地訪問到這個網站都是同樣的用戶數據（針對這種情況我們會使用cdn，部署網路各地的節點伺服器可以使得不同地方的人員訪問網站的速度是一致流暢的）。所以並不是網站業務簡單就輕率的認為網站開發沒有技術含量。
遊戲伺服器，因為可以分區分頻道等，所以很多情況下一台伺服器的負載量要求不會太高。像手游的伺服器，甚至要求可以低至同時在線200人。而且有些時候我們僅需要提高某一些功能的負載量，又或者大型3D遊戲存在地圖，這些情況下，我們往往使用分散式架構來解決。如分離聊天、好友之類的功能，如給每個區域分配一個單獨的房間/地圖/場景伺服器。======================現在來看，覺得最大的差異在於web多數是無狀態伺服器，而遊戲伺服器多數是有狀態的。之前說的高頻低頻問題，web也是存在高頻，如淘寶，如春節的12306.req/resp模式的卡牌類伺服器其實和web差不多。而如那些有地圖的遊戲是會記錄每個玩家的狀態，地圖伺服器還會在伺服器內運行一個類似客戶端的地圖處理邏輯。如同客戶端，伺服器也存在一個刷新頻率。不過一般比客戶端的幀率低很多。大多數伺服器是用單線程輪詢，也有一些多線程，目前了解也不是很多。無法具體的表述。等再研究一下mmorpg伺服器再來更新吧這個我要來答
高中的時候迷戀上了一款網頁遊戲叫「熱血三國」並為之巨大投入，再後來幡然醒悟道具永遠都是有限的，遂自己架設了一個私服。然而多年過去了，我已經是一個軟體專業的學生，主攻java
————割下————首先糾正一個問題，什麼叫做java直接用框架？你要知道java這種狗血的東西用上框架也比php開發周期長，然而題主理所應當的把框架理解為成品了，事實上SSH（struts2+hi+spring）用上了也並不一定減少多少代碼量，不過是一些細節問題給你處理了而已……事實上本質來說，伺服器這個東西都很像，無非就是業務層的伺服器和資料庫的伺服器，如果這麼比較那它還就是一樣的。但是要考慮到通常來說，遊戲對於數據吞吐量要求比較大（一般來說，不要計較那麼多，淘寶那種東西是例外），所以一般來說，遊戲伺服器對於資料庫伺服器要求比較高，因為常在線啊，無時無刻數據交互啊……還有就是版本更新問題，web應用更新是比較安全的，就算失敗了也好控制，但是遊戲這種東西，在線更新，迭代失敗就是災難，猶記得當初一哥們半夜三點起來拿伺服器練手更新，結果……他的老闆是早晨6點來通知他可以換工作的……最後一點就是機房帶寬問題，這個不多少，遊戲要求比較高，當然大型網站要求帶寬也不少。基本沒區別
得加錢。
你是不是想問：長鏈接的伺服器和短鏈接的伺服器的區別？因為很多web伺服器也可以做遊戲伺服器了，都是CURD操作，比如：皇室戰爭
分享一下網易pomelo的文檔：
Pomelo框架概述 · NetEase/pomelo Wiki · GitHubPomelo的設計動機 · NetEase/pomelo Wiki · GitHub一個是長連接，一個是數據放內存
什麼 「遊戲伺服器對於資料庫伺服器要求比較高，因為常在線啊，無時無刻數據交互啊」，這種回答，憋逗了 XD推薦閱讀：