遊戲伺服器架構設計

2022-06-17 11:48:09 字數 3763 閱讀 7664

一、棋牌類伺服器的特點

1,棋牌類不分割槽不分服

一般來說,棋牌遊戲都是不分割槽不分服的。所以棋牌類伺服器要滿足隨著使用者量的增加而擴充套件的需要。

2,房間模式

即在同一局遊戲中就是在同乙個房間中,同乙個房間中的人可以接收到其他人的訊息。

3,每個房間的操作必須是順/序性

這個特性類似與一般遊戲的回合制,每個玩家的操作都是有順序性的。

二、需要解決的技術點

1,資料共享

因為棋牌類遊戲不分割槽不分服,我們在設計伺服器的時候,是按世界服的思想去設計,即伺服器是乙個n多台物理機的集群。當使用者登陸伺服器,建立房間時,可能根據負載均衡演算法,它可以在任何一台伺服器上面。所以,不管使用者登陸到哪一台伺服器上面了,都可以獲得自己的資料。我們可以使用redis來做資料共享。

2,如何進入房間

在同一局遊戲中,我們要求所有人都在同乙個房間中,我們可以規定在同乙個房間中的使用者,必須登陸到同一臺物理伺服器上面。在建立房間完成之後,其他人根據房間號查詢房間的時候,可以根據房間號,獲取這個房間所在的伺服器ip和埠,判斷乙個當前使用者登陸的伺服器ip與房間所在的伺服器ip是否相同,如果相同,就不做切換,如果不一樣,客戶端就使用ip和埠,連線到房間所在的伺服器上面。

3,保證房間操作的順序性

建立房間成功之後,接下來的操作都要保證它的順序性,所以房間需要有乙個它自己的訊息個佇列。我們可以把每個房間到達伺服器的訊息封裝為乙個任務,把這個任務放到訊息佇列中,然後有乙個任務執行者去按順序執行這些任務。

三、系統架構

1,功能設計

a,登陸

一般都是需要接第三方登陸,登陸這一塊是http操作,我們統一提供乙個web服務,用來做登陸驗證。因為在登陸時,呼叫第三方的http服務,這個過程可能很慢,如果放在邏輯伺服器的話,可能會卡業務邏輯任務。因為可能不同的玩家業務請求可能同在乙個執行緒中,如果有任務卡了,那麼這個任務以後新來的請求請會卡住,導致訊息延遲。

b,獲取遊戲公告,也放在web服務中。公告一般是遊戲登陸的時候向伺服器獲取一次。把它放在web伺服器中,與業務邏輯分離的好處是,當業務邏輯伺服器維護或更新的時候,不影響使用者的登陸,和獲取公告,這樣使用者體驗會好一些。

c,建立使用者唯一的id,因為棋牌類遊戲伺服器是世界服,無分割槽,所以使用者的id必須是全域性唯一的。可以利用redis的incr方法,原子的遞增,如果不想被別人根據userid的遞增推算出有多少註冊使用者,遞增的梯度可以隨機,比如每次遞增的值從1到1024中隨機乙個。

d,建立房間,當房間主建立房間時,房間的id需要在任何臺伺服器上可以查詢到,所以建立房間成功後,房間id要儲存在共享記憶體redis中,每個房間id對應乙個房間所在的ip位址或伺服器id.這樣,當有使用者要進入房間,在查詢房間id時,可能判斷這個房間是否和自己登陸的遊戲伺服器相同。

e,查詢加入房間

根據房間id查詢房間,查詢到房間後,獲取房間所在的ip位址或伺服器id,如果發現和自己所登陸的伺服器一樣,直接可以加入房間。如果不一樣,把這個房間所在的ip和埠返回給客戶端,讓客戶端重新與房間所在的伺服器建立連線,使用登陸時的token驗證使用者。

f,遊戲指令碼呼叫

在驗證遊戲是否合法時,客戶端與伺服器都要驗證,驗證的演算法是一樣的,所以可以使用指令碼來寫,寫乙份指令碼,在伺服器與客戶端中同時使用。可以使用lua。同乙個演算法使用同乙個指令碼 ,這樣在開發新的同型別棋牌遊戲時,只需要替換一下這個指令碼就行了,不用再重複開發。

3,後台管理系統

這個一般是根據運營需求開發的,每個公司不一樣。不過有一點,後台管理系統可能要和遊戲伺服器通訊,這種通訊方式最好是採用redis的訂閱/發布機制。這樣可以把某個訊息事件同時傳送到所有的業務伺服器上面。根據使用者所在的伺服器進行處理。

4,玩家同屏

玩家同屏是棋牌遊戲中的乙個重點,對於做過那些大型的arpg,或mmo遊戲的程式設計師來說,這並不是什麼難事。因為同屏就是伺服器對客戶端的訊息進行**。乙個房間四個人,乙個人出的牌或操作能被其他三個人同時看到。

因為棋牌遊戲的同步資料量比較小。一般常見的同步方式有兩種:

1,客戶端主動拉取。

客戶端定時主動向伺服器請求乙個使用者的訊息佇列,當乙個玩家有操作需要同步到其他玩家時,在伺服器端先把這個訊息放到這個使用者的訊息佇列中。等待客戶端的拉取操作。這種方式的好處是,不需要考慮網路閃斷或網路不好的情況,資訊都是同步獲取的。缺點是,定時拉取的時間間隔很短,可能不到一秒就會拉取一次。

2,伺服器主動推送

當乙個使用者出牌的訊息需要同步給其他玩家時,伺服器會獲得這個玩家與伺服器建立的socket連線,然後伺服器使用socket 主動向客戶端傳送訊息。

這種方式要考慮網路閃斷,訊息丟失的問題。因為伺服器推送的訊息,客戶端有可能會收不到。所以客戶端需要根據心跳來判斷網路是否有斷開過,如果有斷開,需要重新從伺服器拉取整個房間狀態的訊息。或者根據伺服器傳送的訊息號,如果客戶端發現接收到的伺服器訊息號有跳號的,比如應該接收10,卻收到了12,說明中間有訊息丟失,需要重新拉取整個房間的狀態資訊。

5,資料同步和持久化

1,由於棋牌類的遊戲資料少,計算量也小,所以完全可以不使用記憶體快取,而直接使用redis共享記憶體,使用者的所有資料都快取在redis中。更新也同步更新到redis中,這樣不管乙個使用者登陸哪一台業務伺服器,都能獲得自己的最新資料。

2,更新資料庫,由於資料第一快取是redis,所以活躍的使用者資料都是可以從redis中直接獲得的,而不用查詢資料庫,所以資料庫的更新可以採取非同步更新,而不會產會資料的延遲。需要注意的一點是,資料的非同步更新必須保證是有順序的。那麼這就會產生乙個問題,怎麼保證使用者的更新不會亂呢?

3,如何保證更新的順序性

因為我們的業務伺服器是多個的,使用者可能連線其中的任何乙個,如果說登陸的是伺服器a,加入的房間在伺服器b上,那麼連線就會切換。為了保證資料更新的順序,我們可以做乙個資料庫持久化服務,把需要更新資料庫的任務實時傳送到這台伺服器上,由資料庫持久化服務執行對資料庫的更新。這樣不管使用者連線的哪台業務伺服器,它的更新都是有順序保證的。

4,一種快速簡單的方法

由於棋牌類的業務少,資料更新少,所以查詢可以有redis快取,減少資料庫查詢的壓力,而更新實行實時更新到資料庫,前期不需要開發資料庫持久化服務。等使用者積累到一定程式之後,發現更新資料庫比較慢的時候,再單獨做乙個資料庫持久化服務。

四、伺服器架構

1,登陸時,客戶端首先向登陸的web伺服器請求登陸資訊,登陸成功之後,返回登陸的token,為了適應大規模的web請求和登陸服務的穩定,可以使用nginx做負載均衡。

2,登陸成功之後,請求負載均衡伺服器,獲取一台連線的業務伺服器。這個負載均衡伺服器可以和登陸web在乙個程序中,也可以獨立出來。

3,拿到登陸成功的token和需要連線的業務伺服器的ip和埠之後,再去連線業務伺服器。連線成功之後,要使用token到登陸伺服器去驗證,這個使用者是否登陸了。

4,同乙個房間的使用者要連線到同一臺物理伺服器上面。在上面已經說過了。

5,redis用來做共享快取。

6,mysql做持久化儲存。

7,資料庫持久化伺服器,統一做資料入庫操作。

五、關於閘道器的問題

1,閘道器的作用

a,**訊息包

b,業務的負載均衡,比如a業務由伺服器a處理,b業務由伺服器b處理,由閘道器進行**。

c,維護與客戶端的連線

d,頻寬的整合,一般的雲服務都是按購買的伺服器計算頻寬的。通過一台伺服器**訊息,可以只購買乙個大頻寬就可以了。以節約成本。

2,棋牌類遊戲需要閘道器嗎?

我認為不太需要,因為棋牌類遊戲業務比較單一,做的最多的就是訊息同屏**。最多是再有一些任務或活動,這些由一台伺服器直接處理完全可以搞定。而且開發閘道器也是乙個複雜的工作,沒必要在這個上面花太多的時間。

棋牌遊戲伺服器架構設計

一,棋牌類伺服器的特點 1,棋牌類不分割槽不分服 一般來說,棋牌遊戲都是不分割槽不分服的。所以棋牌類伺服器要滿足隨著使用者量的增加而擴充套件的需要。2,房間模式 即在同一局遊戲中就是在同乙個房間中,同乙個房間中的人可以接收到其他人的訊息。3,每個房間的操作必須是順序性 這個特性類似與一般遊戲的回合制...

百萬使用者級遊戲伺服器架構設計

伺服器結構 登入服的負載均衡 伺服器結構 簡單的世界服實現 我們來看看結構圖是怎樣的 伺服器結構 繼續世界服 伺服器結構 最終的結構 伺服器結構 一點雜談 登入服的設計 功能需求 伺服器公共元件實現 訊息佇列 伺服器公共元件實現 發包的方式 伺服器公共元件實現 狀態機 伺服器公共元件 事件與訊號 再...

網路遊戲伺服器端架構設計

一款大型的網遊的開發主要由遊戲策劃,伺服器端,客戶端,美工,遊戲測試,使用者體驗等幾部分組成,其中伺服器端的開發絕對是乙個程式設計師大展身手的地方。只要你崇拜技術,熱愛程式設計,在伺服器端開發的世界裡就有你的光芒。下面談一談伺服器端的整體架構。伺服器端的整體架構如上圖所示,首先,auth就是玩家的登...