談架構，先聊聊游戲業(yè)務特點。

1 、難點在于時間復雜度是以N ^ 2 進行增長的，以平方的級別增長的。具體業(yè)務展示為，如移動， 一個人移動要通知其他人，N個人移動就是N * (N - 1), 以平方級別增長的。如世界聊天等。所以很多游戲采取分服分線的策略。當然還有風險問題，現(xiàn)在的用戶成本居高不下，一千人的服務器的成本都就上萬了，出點技術問題，一個服流失點人都能虧幾千，幾萬，人數(shù)攀上去風險太高。

2 熱點問題。具體業(yè)務展示為，攻城戰(zhàn)，幫會戰(zhàn)等。策劃的業(yè)務需求，人多熱鬧，特別了設定場景人能重疊，就更甚了。跟12306火車訂票的問題有點像，只是數(shù)量級不在一個級別而已。不過有個問題就是客戶端承受不了，手機同屏100不到就不行了，網(wǎng)頁flash同屏也就200來人卡得飛起，客戶端倒是能達上千。然而游戲服務器做上千同屏問題不大。

3 、高響應速度，基本需要在50ms以下的響應速度。因為加上網(wǎng)絡延遲就能到100ms, 玩過lol或者王者榮耀，當延遲超過100ms會有卡頓感，過了200ms,很多都沒法玩的了。很多別的領域甚至能到達秒級別響應就好，但游戲不行。不過游戲的業(yè)務里并不是全部都要求高響應的，高響應的主要在場景同步上，主要在移動，戰(zhàn)斗上面，玩家響應速度會有最直觀的感受，但對于一些公會申請之類的，那些的響應需要更偏向傳統(tǒng)領域，1秒也是能接受的，但最好還是都在500ms一下。當然不同游戲類型的響應速度的要求不一樣。當年做傳奇，移動間隔是550ms,所以其實不超過200ms也是可以的，到500ms,就是一步一卡了。當然或許就是使用物品什么的會有一些稍稍的卡頓感。

4 、數(shù)據(jù)一致性要求高。這塊是接近電商，金融的需求。物品因為某些原因，如bug, 突然多的，玩家會去刷，破壞游戲平衡，少了會導致用戶流失。包括在數(shù)據(jù)丟失的時候，也得數(shù)據(jù)一致。畢竟有可能就是剛好沖了值，結果數(shù)據(jù)一丟，沖的錢沒有了。

5 、數(shù)據(jù)安全這塊，倒是不太重。允許丟失數(shù)據(jù)，正如社交能丟失聊天記錄。但不能太長，最多也就是5分鐘，因為太長玩家會有白玩的感覺。當然最好就是不丟，但在災難面前，丟5分鐘數(shù)據(jù)真的是小事，以前在9377的時候，有丟了1，2個月數(shù)據(jù)的事件。前段時間，還有騰訊云還把別人公司的數(shù)據(jù)全丟了，關鍵是數(shù)據(jù)一致性。

6 、寫數(shù)據(jù)比讀數(shù)據(jù)多。在所有的業(yè)務當中，移動是占據(jù)98%比重，移動一次得記錄下坐標。所以，寫比讀多。

7 、數(shù)據(jù)量比較小，一個服的數(shù)據(jù)，運行一個月導出來，可能就是幾百M頂天了，不過這個更多是因為單服人數(shù)的關系。最后一個服平均就是100來人。

8 、游戲服務器的是有狀態(tài)的，重啟玩家會掉線，有Bug需要極速修復，而且不允許輕易重啟。因為寫比讀多，而且還是多太多，所以一般都得做緩存，重啟會導致緩存丟失。不像一些領域可以數(shù)據(jù)都存數(shù)據(jù)庫，讓服務器無狀態(tài)，隨時重啟。

9 、跨服，合服需求

其他的需求就跟別的領域差不多

1 、開發(fā)效率，協(xié)作效率，上手難度

2 、線上查Bug，容錯能力

3 、宕機處理,容災

現(xiàn)在開始聊聊解決方案

1 、計算時間復雜度這個問題，其實一般采取同屏廣播，集中分發(fā)就可以解決。甚至不處理都可以，因為更多時候是客戶端限制，用戶量沒到那個位置。當然哪怕是到一定量的用戶量(起碼單服上萬)才需要考慮這種問題。當然根本解決這個問題的方法是做集群，就是同時幾臺機器承載同一張地圖的場景運算就行了（當然這里也有一些坑跟問題，方案最多上限估計在100萬，因為帶寬先炸了）。但是最關鍵還是一個，成本問題�；ヂ�(lián)網(wǎng)創(chuàng)業(yè)有個基礎是邊際成本為0，或者是在用戶量大接近0。然而這種方式是邊際成本會越來越高。所以基本上采取分服分線的策略

2 、熱點問題，業(yè)務需求，沒法解決。

3 、高響應，一般游戲至少30幀，每幀30ms。但其實服務器真不需要讓響應時間到30ms, 一般玩家一個動作就是10幾幀，最少都有8幀,在動作結束前響應就行。100ms以下基本ok,除了一些像王者榮耀那種，需要高精度的，可能特殊處理。

4 、數(shù)據(jù)一致性，其實在比較常規(guī)，一般采取事務處理解決

5 、數(shù)據(jù)安全這塊，一般采取宕機寫入數(shù)據(jù)，一般不會丟數(shù)據(jù)，除非是有硬件損壞，或者系統(tǒng)崩潰。一般不會丟，而且最多也只會丟5分鐘數(shù)據(jù)。

6 、寫數(shù)據(jù)比讀數(shù)據(jù)多。這個其實也比較常規(guī)，一般采取緩存解決。

7 、游戲服務器的是有狀態(tài)的，這個很多時候我們會采取熱更新。以前甚至是直接把業(yè)務接口設計成插件，進行動態(tài)庫重新加載的處理。還有快速重啟這些策略

8、 跨服，其實數(shù)據(jù)訪問的問題，還有一致性的問題。

9 、開發(fā)效率，協(xié)作效率，上手難度。服務器框架采取很多都是面向接口+面向對象，以保證協(xié)作，以及開發(fā)效率

10 、線上查Bug,一般就是日志 + core dump，還有一些監(jiān)控工具，如top之類的。

11 、宕機一般就是安全關服，做各種數(shù)據(jù)保存。當然還有數(shù)據(jù)庫宕機這些處理，業(yè)務拆分成分布式，進行進行分區(qū)容災。

結果總體看來，數(shù)據(jù)的問題，線上查錯，容災，熱更這些才是重點問題。而事實上在以前，會有網(wǎng)絡問題，因為epoll跟iocp還沒有出現(xiàn)，大家還用的select, 著名的c10k問題，所以架構上都會有網(wǎng)關的設定。還有就是這10年計算機的性能翻了很多倍，著名的摩爾定律了解一下，當年單機做1000人都是問題�，F(xiàn)在都是不是問題。現(xiàn)在單線程 + 無阻塞隊列，都能達到2000+，如果用上一些高頻的機器，甚至可能達到5000人。以前很多的問題都不是問題了。

接著介紹一些架構具體的方案。

單線程 + 無阻塞隊列

這個架構的重點在于業(yè)務線程不能有阻塞，其他IO異步，一些重計算的，排行榜(堆排序)，聊天(ac自動機)等需要特殊算法進行優(yōu)化，或分布式架構，拆分出來。

當然可能會遇到一些問題

1、 無鎖編程(并不是必要，可以簡單隊列處理)

2 、多線程死鎖問題

3、 跨服會比較麻煩，因為架構耦合比較嚴重，一般建個新服做為跨服，進入跨服數(shù)據(jù)同步過去，等退出跨服，再把數(shù)據(jù)反向同步回來

4 、單點問題，一旦不可用，就是整體不可用

特意說一下這個,這個的設計的目的是為了實現(xiàn)服務器無狀態(tài)，把狀態(tài)存進去redis里面，主要游戲服務器基本都是有狀態(tài)的，需要保存一些狀態(tài)的數(shù)據(jù)。當然有些類別可以做成無狀態(tài)，如卡牌。不保存狀態(tài)，就能實現(xiàn)快速重啟，數(shù)據(jù)，邏輯分離好處多多。但并不是所有業(yè)務都能用，redis在單鏈接大概在2萬qps，多鏈接確實能到10萬qps。對于大部分業(yè)務是可以的，很多都是低頻業(yè)務，但對于一些高頻的，同屏100人用這個扛不住的。

分布式架構

這個架構的重點在于服務器拆分，一般按著業(yè)務，數(shù)據(jù)一致性進行拆分。

當然也會遇到一些問題

1 分布式數(shù)據(jù)一致性問題（最麻煩的問題，雖然說有通用方案，就是做分布式事務，采用最終一致性進行妥協(xié)，但很多公司的做法是不理，因為麻煩，通過把數(shù)據(jù)冗余盡量把分割的功能合在一起，策略采取先扣除，出問題，客服人工補）

2 調(diào)用鏈問題，因為功能割裂，有些時候問題查找麻煩（日志跟蹤麻煩，因為功能割裂，日志分布在不同的服務器上）

3 運維的工作量劇增，或許需要開發(fā)一些額外的工具

4 單點問題不可用（網(wǎng)絡不可用，機器不可用）

5 一些特殊的業(yè)務得做冗余設計，做緩存系統(tǒng)

其實可以明顯對比，分布式架構要做要解決的問題會相堆比較多，所以有足夠的人力才去做,所以這也是個考量的要素之一。

當然不同游戲類型，架構會稍微不一樣，簡單介紹一下

mmorpg 前面說過服務器拆分是依據(jù)數(shù)據(jù)一致性的，在mmorpg中，場景的數(shù)據(jù)是比較重要的，不像回合制，場景物體與人物，數(shù)據(jù)同步量比較大，做數(shù)據(jù)一致性比較麻煩，一般會把場景角色管理合為一體，如在場景撿一個物品，進入背包，人物血量同步,技能同步等。

棋牌游戲，壓力會在于各種子游戲跟機器人上面，所以會采取按游戲拆分，每場游戲再進行數(shù)據(jù)同步，有業(yè)務的特殊性，網(wǎng)關規(guī)避攻擊，規(guī)避監(jiān)管。

架構設計，其實更多是為了解決問題，像一些流行的微服務，其實主要為了是解決在大量人力同時做一個項目，在溝通成本急劇上漲情況下，進行合理拆分，減少溝通成本。

這是一篇總起的文章，因為這些細節(jié)的解決方案，都能各自成為一篇文章。篇幅有限。后面會開始說細節(jié)。

數(shù)據(jù)存儲策略

mysql的我們需要了解的技術細節(jié)

mysql的一些高可用方案

redis的我們需要了解的技術細節(jié)

游戲業(yè)務上常用的算法

lua熱更新思路

地圖，場景同步方案

跨服實現(xiàn)

數(shù)據(jù)一致策略，事務處理

自動化測試搭建

一些編碼上的小技巧（防死循環(huán)）

一些有趣的設計架構（多租戶架構）

更詳細架構方案（mmorpg等）

租用游戲服務器選擇天下數(shù)據(jù)！天下數(shù)據(jù)已經(jīng)成為國內(nèi)最大的海外服務器IDC服務商，服務器、數(shù)據(jù)中心解決方案發(fā)展成熟，各大行業(yè)上市企業(yè)也熱衷于與天下數(shù)據(jù)合作，省心、省事、省時。天下數(shù)據(jù)已為眾多企業(yè)提供最安全的海外游戲解決方案、游戲數(shù)據(jù)安全解決方案、游戲服務器配置安全、游戲服務器架設方案。

本文鏈接：http://m.51huadong.com/cloundnews/11002906.html