談架構(gòu)，先聊聊游戲業(yè)務(wù)特點。

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

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

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

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

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

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

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

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

9 、跨服，合服需求

其他的需求就跟別的領(lǐng)域差不多

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

2 、線上查Bug，容錯能力

3 、宕機處理,容災(zāi)

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

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

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

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

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

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

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

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

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

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

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

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

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

接著介紹一些架構(gòu)具體的方案。

單線程 + 無阻塞隊列

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

當(dāng)然可能會遇到一些問題

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

2 、多線程死鎖問題

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

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

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

分布式架構(gòu)

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

當(dāng)然也會遇到一些問題

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

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

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

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

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

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

當(dāng)然不同游戲類型，架構(gòu)會稍微不一樣，簡單介紹一下

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

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

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

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

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

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

mysql的一些高可用方案

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

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

lua熱更新思路

地圖，場景同步方案

跨服實現(xiàn)

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

自動化測試搭建

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

一些有趣的設(shè)計架構(gòu)（多租戶架構(gòu)）

更詳細架構(gòu)方案（mmorpg等）

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

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