A brief talk on the roll dress game if you implement a key fit

This is a creation in Article, where the information may have evolved or changed.

Original Address-Blackbeard BLOG:HTTP://WWW.BUGCLOSED.COM/POST/12

Background

In recent years in the game industry, there have been a variety of roll dress games, including page tours, hand tours, H5 games and so on. The difference between the game and the big dress game is that the number of players at the same time, the big game is a lot of users play together, even dozens of millions of gamers. And the game is generally designed to play the game online limit, such as 3000, to reach the upper limit of a new set of servers, and guide users into the district.

The rolling mode is a game type, technical architecture and a quick success of the pit money strategy and other factors together decided, big dress games include most of the end of the tour, as well as the type of COC such a game. In addition, although like the League of Legends, the glory of the game also divided into the architecture, but this is not my understanding of the "roll the game", first of all, although they sub-service, but the maximum number of each service can be as high as hundreds of thousands of, they do not occur frequently in the case of a suit. The game is more game strategy design, encourage players to spend money to take a shortcut overdraft game life cycle, or even a few days to dominate a server. So that other players can not catch up, even if the cost of money chasing is very low, it is better to enter a new service to start again. This led to a new service, players are flocking, scrambling to upgrade equipment, in order to enter the forefront of the fastest, if efforts to find a backward, may only wait for the next new service. This also led to the new service number of hot, old clothes slowly become a village clothes, and even no one's death clothes. In order to save the server bandwidth resources, at the same time so that a few remaining players can play, it is necessary to carry out frequent suits, a number of unrelated server players, merged into a service, so that a wave of players to compete and reap.

Combined Clothing

The previous mention of the two modes of roll and big clothes, regardless of which mode, the time of the suit, it is necessary to combine the game data of multiple services together. Regardless of whether the database is Mysql,redis or MongoDB, the merging of database tables is a compatibility problem that requires more data merging, no conflicts or omissions. such as MySQL, you need to ensure that the table merge when the primary key does not conflict, if the business has a nickname is not duplicated settings, but also need to ensure that the nickname is not duplicated. Sometimes merging also needs to delete zombie data, it is important to note that the logical relationship between the deleted data is cleared together, can not result in inconsistent data, such as the elimination of a half-year non-online player account data, but in friends or gangs still remain relationship.

Single Service architecture

Business model to a certain extent will determine the selection of technology, in the roll-up mode, the game online requirements are relatively low, usually a single process architecture is enough to support. The so-called single-service architecture, and not necessarily the entire background only a server process, there may be other worker processes, but the main game logic will only have a process, and the schema does not support the game process scaling, to reach the process or the physical server limit, that is, from the operation of re-opened the service to guide new players into the district, The single-service architecture can be easily understood as the following architectural pattern:

It can be seen that each group of servers has its own independent game process and database, the user between the different servers is physically isolated. The advantages of this architecture are simple and easy to develop, server isolation, a set of servers need to stop tuning or downtime, will not affect other services. The disadvantage also comes from the single-service deployment, where you need to redeploy the database and game services environment for each new service. The physical consolidation and migration of the database is required for the combined service.

In a single-service architecture, a hard merge of physical database tables is required, and it is important to note whether primary key fields conflict. There are two ways to prevent primary key collisions:

• All primary keys are modified at the time of the suit, especially the UID, to ensure they come from different spaces.
• At the beginning of the design is to consider the problem of the uniform, so that the data in the allocation of unique UID, each service can be segmented processing, to ensure that the primary key UID from the beginning of each service will not conflict.

The steps and operations of the suit are generally fixed, and can be processed uniformly for their own specific business model and table-structured script.

Big Service Architecture

The Big service architecture is different from the single service architecture is can carry more online players, while there is a certain degree of scalability, to a certain extent, through the continuous deployment of new servers to expand online capacity. In the rolling mode of the game, you can also use the design ideas and architecture of large suits, so that in operation and maintenance management and the service is greatly facilitated, the structure is as follows:

Of course, this is similar to the distributed architecture diagram of the end-trip, but it is also different, because the business scenario here is used in the roll-up game. The architecture is a schematic illustration, not an online operation structure, different developers will have different specific ideas and design preferences, such as friends, unions and so on are not listed, here only to explain the principle of analysis.
As you can see, there are a number of different roles, described below:

• Database, the entire schema only a unique db, all the data are stored centrally;
• DBServer, all operations on the database are performed through dbserver, ensuring that the business logic separates the details of the database design;
• Account/name, the uniqueness of the user ID or nickname is guaranteed, this service is the whole region only;
• Gameserver, Game logic services, here each gameserver is a logic service, through the continuous deployment of new gamesever that realize the open service;
• Login, login logic and routing assignment, here is the key to a key, in the Fit policy configuration to save which service assigned to which Gameserver game process address, only need to adjust this policy configuration to control user access to the gameserver process;

Large Service Architecture User Login process:

1. The user can login to the interface of the client to select the entrance of 3, and click into the game.
2. The login module receives a request from the user to enter S3, and returns to the S3 Gameserver entry address from the Fit policy configuration.
3. The client receives S3 's Gameserver address and initiates a link request directly to S3.
4. GameServer3 processes the login request and returns the user information from the DBServer to the user, without information creating a new role.
5. Login completed, entered the S3 clothing.

and single-service architecture of the difference between the suit

Single-service architecture, the reason for data processing and migration, mainly 2 reasons:

• Each service database is in a detached state and needs to be physically merged together
• Primary key unique ID and other information conflict, require database repair processing

Because of these 2 reasons, the single-service needs to do a lot of data processing, export, copy, migration, and so on, increased the process complexity of the operation and the possibility of error. From the big service architecture diagram can be found that the single-service architecture of the 2 of the difficulties have been naturally eliminated. The account assigns a unique ID, the storage in the DB does not conflict, and the data is placed in a library, there is no problem to migrate.

One-touch fit

By the above decomposition can be found that the perfect fit will be very convenient now, without modifying and migrating data, or even do not have to stop, only through a tool in the service strategy configuration library to modify the selection of information, modify the user's login game server. For example, to provide a Web modification page, select S1,s2,s3 to merge, by default after the merger is provided by Gameserver1 service, Gameserver2 and Gameserver3 can stop the rack, only need an HTTP request, will S2, The Gameserver address of the S3 is modified to Gameserver1, that is, the merge is implemented.
After-service user login process:

1. The user also chooses the entrance of the 3 service to login the game.
2. Login module to get the user to enter the S3 clothing, query the policy configuration, get S3 service address, that is, Gamesrver1, return.
3. The user obtains the Gameserver1 address, initiates the link request, carries on the login.