Card Game Server Architecture Design

Intuitive chess and card game design worthy of reference
http://www.youxijishu.com/h-nd-157-2_323.html

1. Features of
chess and card servers
Regardless of division or service. Therefore, the chess and card server should meet the needs of expansion with the increase of the number of users.
2. Room
mode In the same game, people in the same room can receive messages from other people.
3. The operation of each room must be sequential.
This feature is similar to the turn-based game in general, and the operations of each player are sequential.
Second, technical points that need to be solved
1. Data sharing
Because chess and card games are not divided into different servers, when we design the server, we design it according to the idea of ​​​​the world server, that is, the server is a cluster of n multiple physical machines. When a user logs in to the server and creates a room, it can be on any server according to the load balancing algorithm. Therefore, no matter which server the user logs in to, they can obtain their own data. We can use redis for data sharing.
2. How to enter the room
In the same game, we require everyone to be in the same room. We can stipulate that users in the same room must log in to the same physical server. After the room is created, when other people search for the room according to the room number, they can obtain the server ip and port where the room is located according to the room number, and determine whether the server ip logged in by a current user is the same as the server ip where the room is located, if they are the same , do not switch, if not the same, the client will use the ip and port to connect to the server where the room is located.
3. Ensure the order of room operations
After the room is created successfully, the next operations must ensure its order, so the room needs to have its own message queue. We can encapsulate the message arriving at the server from each room as a task, put this task in the message queue, and then have a task executor to execute these tasks in order.
Third, system architecture
1, function design
a, login
generally requires a third-party login. This part of login is http operation. We provide a unified web service for login verification. Because when logging in, the third-party http service is called, this process may be very slow, and if it is placed on the logical server, business logic tasks may be stuck. Because different players' business requests may be in the same thread, if a task is stuck, new requests from this task will be stuck in the future, resulting in message delay.
b, get the game announcement, also put in the web service. The announcement is generally obtained from the server once when the game is logged in. The advantage of putting it in the web server and separating it from the business logic is that when the business logic server is maintained or updated, it does not affect the user's login and access to announcements, so the user experience will be better.
c. Create a user's unique id. Because the chess and card game server is a world server and has no partitions, the user's id must be globally unique. You can use the incr method of redis to increase atomically. If you don't want others to calculate how many registered users there are based on the increment of userid, the incremental gradient can be random, for example, the value of each increment is random from 1 to 1024.
d. Create a room. When the room owner creates a room, the id of the room needs to be queried on any server, so after the room is created successfully, the room id should be stored in the shared memory redis, and each room id corresponds to a room where the room is located. IP address or server id. In this way, when a user wants to enter the room, when querying the room id, it is possible to determine whether this room is the same as the game server that he logged in to.
e, find join room
Query the room according to the room id. After finding the room, get the ip address or server id where the room is located. If you find the same server as the one you log in to, you can directly join the room. If not, return the ip and port where the room is located to the client, let the client re-establish a connection with the server where the room is located, and use the login token to authenticate the user.
f. Game script call
When verifying whether the game is legal, both the client and the server must verify, and the verification algorithm is the same, so you can use a script to write, write a script, and use it in both the server and the client. You can use lua. The same algorithm uses the same script, so when developing a new chess and card game of the same type, you only need to replace the script without repeating the development.
3. Background management system
This is generally developed according to operational needs, and each company is different. However, there is one point that the background management system may have to communicate with the game server. This communication method is best to use the subscription/publishing mechanism of redis. In this way, a message event can be sent to all business servers at the same time. Processed according to the server the user is on.
4. Players on the same screen
Players on the same screen is a key point in chess and card games. For programmers who have done those large-scale arpg or mmo games, this is not difficult. Because the same screen is the server forwarding the client's message. There are four people in a room, and the cards or actions played by one person can be seen by the other three at the same time.
Because the amount of synchronized data in chess and card games is relatively small. There are two common synchronization methods:
1. The client actively pulls.
The client periodically actively requests a user's message queue from the server. When a player has an operation that needs to be synchronized to other players, the server first puts the message into the user's message queue. Waiting for the client's pull operation. The advantage of this method is that there is no need to consider the situation of network interruption or poor network, and the information is obtained synchronously. The disadvantage is that the time interval of timed pulling is very short, and it may be pulled once in less than a second.
2, the server actively pushes
When the message of a user playing cards needs to be synchronized to other players, the server will obtain the socket connection established by the player and the server, and then the server will use the socket to actively send messages to the client.
In this way, the problem of network flash and message loss should be considered. Because of the message pushed by the server, the client may not receive it. Therefore, the client needs to judge whether the network has been disconnected according to the heartbeat. If there is a disconnection, it needs to re-pull the message of the entire room status from the server. Or according to the message number sent by the server, if the client finds that the received server message number has a skip number, for example, it should receive 10, but received 12, indicating that there is a message loss in the middle, and the state information of the entire room needs to be pulled again.
The disadvantage of this method is that the development is complicated and some network issues need to be considered. The advantage is that it will only be pushed when there is a message, if not, it will not be pushed, and it will not occupy system resources such as bandwidth, which can increase the number of simultaneous online users, that is, increase the load of the server.
5. Data synchronization and persistence
1. Because the game data of chess and cards is small and the amount of calculation is small, it is completely possible to not use the memory cache, but directly use the redis shared memory, and all the user's data is cached in redis. Updates are also updated to redis synchronously, so that no matter which business server a user logs in to, they can get their latest data.
2. Update the database. Since the first data cache is redis, active user data can be obtained directly from redis without querying the database, so the database update can be asynchronously updated without causing data delay. . One thing to note is that asynchronous updates of data must be guaranteed to be sequential. Then this will cause a problem, how to ensure that the user's update will not be messed up?
3. How to ensure the order of updates
Because we have multiple business servers, the user may connect to any one of them. If the login is on server A and the joined room is on server B, then the connection will be switched. In order to ensure the order of data updates, we can make a database persistence service, and send the tasks that need to update the database to this server in real time, and the database persistence service will perform the database update. In this way, no matter which business server the user connects to, its update is guaranteed in order.
4. A fast and simple method
Since there are few chess and card businesses and fewer data updates, the query can be cached by redis, reducing the pressure of database query, and the update is updated to the database in real time, and there is no need to develop database persistence services in the early stage. After the user accumulates a certain program and finds that updating the database is relatively slow, create a database persistence service separately.
Fourth, server architecture

1. When logging in, the client first requests the login information from the login web server. After the login is successful, the login token is returned. In order to adapt to large-scale web requests and the stability of the login service, nginx can be used for load balancing.
2. After the login is successful, request the load balancing server to obtain a connected business server. This load balancing server can be in the same process as the login web, or it can be independent.
3. After getting the successful login token and the ip and port of the business server that needs to be connected, connect to the business server. After the connection is successful, you need to use the token to go to the login server to verify whether the user is logged in.
4. Users in the same room should connect to the same physical server. It has been said above.
5. Redis is used for shared cache.
6, mysql does persistent storage.
7, the database persistence server, unified data storage operation.
Five, about the gateway question
1, the role of the gateway
a, forwarding message packets
b. Load balancing of services, for example, service A is processed by server a, service B is processed by server b, and forwarded by the gateway.
c. Maintaining the connection with the client
d. Bandwidth integration. For general cloud services, the bandwidth is calculated according to the purchased server. By forwarding messages through a server, you can only buy a large bandwidth. to save costs.
2. Do chess and card games need a gateway?
I don't think it's necessary, because the chess and card game business is relatively simple, and what we do most is to forward messages on the same screen. At most, there are some tasks or activities, which can be handled directly by a server. And developing a gateway is also a complex job, and there is no need to spend too much time on it.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326232517&siteId=291194637