一，棋牌類伺服器的特點

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，頻寬的整合，一般的雲服務都是按購買的伺服器計算頻寬的。通過一臺伺服器轉發訊息，可以只購買一個大頻寬就可以了。以節約成本。

f，閘道器還可以抵禦一些攻擊，洩流，防止伺服器因流量猛增而卡死。

2，棋牌類遊戲需要閘道器嗎？

我認為前期不太需要，因為棋牌類遊戲業務比較單一，做的最多的就是訊息同屏轉發。最多是再有一些任務或活動，這些由一臺伺服器直接處理完全可以搞定。而且開發閘道器也是一個複雜的工作，沒必要在這個上面花太多的時間。但是如果團隊技術實力足夠的話，建議新增閘道器。

技術交流，歡迎留言，也可新增QQ交流群：66728073，197321069