はじめに：
。ゲームサーバアーキテクチャと実装のいくつかの最近の研究では、いくつかは、私は慎重にそれを読むことを意図し、良い感じがあります実現githubの上でいくつかのオープンソースを見つける
ゲームサーバーの様々な、ここでは主にされたベースのチェスゲームの状態の同期化エントリの、^ _ ^。
列のケーススタディ：
cashino-サーバー（gitのアドレス、クリックしてくださいここで）このプロジェクトは、中国語で書かれているように見える、あなたはドキュメントや提出者からの少しの手がかりを見ることができますが、コードが認識に基づいているnodejs、唯一のバックエンドミドルウェアはRedisのです。
プロジェクト非常に強力な、分散バージョン、強い拡張性を実現するために言うことができる。新しいチェスゲームを追加して、あなたは一定のルーチンを達成することができます。2、ゲームの現在の主な成果、揚げテキサス、ゴールデン、基本的に中国と外国の人々が^ _ ^、エンターテイメントを愛しました。
アーキテクチャの解釈：
一般的なチェスゲームは、ホールサーバや特定のゲームを持っている（部屋）サーバーアーキテクチャここで達成するも例外ではありません。
ホールサーバ（セットロビー、ユーザー、ゲートウェイ）、および特定のゲームサービスから成ります（cashino）ゲーム全体のサービスアーキテクチャが放棄作る従来の測位サービス登録とルーティングモードを巧みに借りたが、サブスクライブ・モデルをパブリッシュ店の中央の部屋オフ、リアルタイムのユーザーデータを統合する。クライアントは、もはやソケットの直接接続から他を必要としますルームサービス、ロビーサービス自体はステートレスなマルチノード展開かもしれません。もちろん、このすべてはRedisの信用、またはRedisの魔法の使用のプロジェクトです。
ログインサーバとゲームサーバとの間で、何の直接的な相互作用のhttp / RPCはありません、パブリッシュおよびサブスクライブ関係のRedisの唯一の援助を達成するためにキュー。これは、このプロジェクトおよび他の従来のチェスゲームサービスアーキテクチャの最大の違いです。
メッセージメカニズムに：
クライアント（H5、アンドロイド/ IOS）及びログインサーバ後続のメッセージインタラクションは長いリンクを通過ログイン・サーバを介して行われるのWebSocket内蔵されている。
内部サービスのメッセージ通信機構を、上記の図に構成されました。パブリッシュ/サブスクライブ・メッセージ・キューによって、完全な達成するために
、メッセージの部屋に送られた選手の、部屋関連するキューのプッシュメッセージに、ログイン・サーバ・ノードによって、対応するゲームサーバノードは、逆に。メッセージを消費し、プロセスになるプレーヤーのための部屋を送ります情報は、プッシュメッセージを対応するユーザキューに、ログイン・サーバ・ノードに対応する受け入れ、そしてプレイヤーへの復帰を同期させる。う
ログインサーバとゲームサーバ同士が直接相互作用しない、とプレイヤー異なるログイン・サーバ・ノードに上陸した同一とすることができますと遊ぶ部屋。
全体的な印象：
3年前に書かれたcashino-Serverは、それはまだ実用化の実際のテストを経験していない、研究試作段階のタイプに属している必要があります。
内部の相互作用を解決するためのパブリッシュ・サブスクライブ・モデルのアーキテクチャの元の側に、巧妙な使用を持っています複雑さは、フレンドリーでの拡張の設計が簡単に新しいゲーム（チェス部屋のカードモード）を拡張することができますが、唯一のライン上のゲーム自体ロジックに集中する必要があります。
概要：
フォローアップは、プロジェクトの下でより多くの知識を獲得するから希望のメッセージを研究するために、より詳細な分析を記事を書きます。