Introduction:
Recent studies of some of the game server architecture and implementation, find a few open source on github realize there are a few feel good, I intend to carefully read it.
The game server variety, here is mainly based chess game state synchronization for entry, ^ _ ^.
Column Case study:
cashino-Server (git addresses, please click here ) This project seems to be written in Chinese, you can see a little clue from the document and the submitter, the code is based on the realization nodejs, the only back-end middleware is redis.
Project very powerful, it can be said to achieve a distributed version, strong scalability. adding a new chess game, you can achieve a fixed routine. the current main achievement of the 2 games, Texas and Golden fried , basically Chinese and foreign people loved entertainment, ^ _ ^.
Interpretation of Architecture:
general chess game has a hall server and the specific game (room) server architecture to achieve here is no exception.
Which consists of a hall server (set lobby, user, gateway), and specific game service (cashino) make up the whole game service architecture abandoned the conventional positioning service registration and routing mode , cleverly borrowed publish subscribe model to integrate real-time user data off the center room of the store. the client no longer needs the other from the socket direct connect room service, lobby service itself may be stateless multi-node deployments. of course, all this is redis credit, or the project of the use of the magic of the redis.
Between the login server and the game server, there is no direct interaction http / rpc, only the aid of publish and subscribe relationship redis queue to achieve. This is the biggest difference this project and other conventional chess game services architecture.
On the message mechanism:
the client (h5, android / ios) and login server is built on long link websocket subsequent message interaction is through transit login server.
The internal service its message communication mechanism, as constructed in the above figure . to achieve full by the publish / subscribe message queue
of players sent to the room of the message, by login server nodes into the room associated queue push message, the corresponding game server node will consume and process messages. On the contrary send rooms for players the information, to the user queue corresponding push message, corresponding to the login server node will accept, and synchronize return to the player.
login server and a game server does not directly interact with each other, and landed on the player different login server nodes can be the same a room to play with.
Overall impression:
cashino-Server written three years ago, it should still belong to the type of research trial stage, did not experience the real test of commercialization.
Has its original side, clever use of the publish-subscribe model architecture to solve the internal interactions complexity, while the design of the expansion of friendly and can easily extend new games (chess room card mode), only need to focus on the game itself logic on the line.
Summary: The
follow-up will write articles, more in-depth analysis to study under the project, the message of hope from acquiring more knowledge.