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 link] (HTTP://WWW.BUGCLOSED.COM/POST/12): 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. # #合服前面提到滚服和大服两种模式, regardless of the mode, it is time to combine the game data of multiple services. 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 choice of technology, in the roll-up mode, the number of online game 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, cancan have other auxiliary 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 upper limit, that is, from the operation to re-open the service, to guide the new players into the district, single-service architecture can be simply understood as the following architectural pattern:! [Write a description of the picture here] (https://img-blog.csdn.net/20180513143736440?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RodW5kZXI1NDAwNw== /FONT/5A6L5L2T/FONTSIZE/400/FILL/I0JBQKFCMA==/DISSOLVE/70) is visible, each group of servers has its own independent game process and database, the user between 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: + Modify all primary keys when you are in uniform, 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 from the beginning of the primary key UID 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 architecture differs from a single service architecture in that it can host more online players while still having a certain degree of scalability, to a certain extent, by continuously deploying 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, thus in the operation and maintenance management and the service has been greatly facilitated, the structure is as follows:! [Write a description of the picture here] (https://img-blog.csdn.net/20180513144059171?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RodW5kZXI1NDAwNw== /FONT/5A6L5L2T/FONTSIZE/400/FILL/I0JBQKFCMA==/DISSOLVE/70) Of course, this is similar to the distributed architecture diagram of the end-of-tour, 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 architecture, different developers will have different specific ideas and design preferences, such asSimilar to friends, unions, etc. are not listed, here only the principle of analysis. As can be seen, there are several different roles, described as follows: + 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, to ensure the uniqueness of the user ID or nickname, this service is the only one in the whole region, + gameserver, game logic service, here each gameserver is a logic suit, through the continuous deployment of the new gamesever that realize the open service; Login, login logic and routing assignment, here is the key to one-touch, 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 the user into 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 retrieves the user information from the DBServer back to the user, creating a new role with no information. 5. Login completed, entered the S3 clothing. # # # and single-service architecture of the combination of different single-service architecture, the reason for data processing and migration, the main reason is 2 reasons: + each service database is in a separate state, need to physically merge together + primary key unique ID and other information conflicts, need database repair processing because of these 2 reasons, The result is that a large amount of data processing, export, copying, migration and so on can be done, which increases the complexity of the process 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. # # # # A Touch of the above decomposition can be found, and now it is extremely convenient; no need to modify and migrate data, or even do not 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. Combined ClothingAfter the user login process: 1. The user also chooses the entrance of the 3 service to login the game. 2. The login module obtains the user to enter the S3 clothing, inquires the collocation policy disposition, obtains the S3 service address, namely Gamesrver1, returns. 3. The user obtains the Gameserver1 address, initiates the link request, carries on the login. 420 reads