一、棋牌類伺服器的特點
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就是玩家的登...