What am I thinking when I design a game server? (1)

Chance coincidence, I was fortunate to be able to design a game server from scratch. In the middle of a lot of laughter and sad tears, here to share.

The game server architecture of my previous project group is as follows:

650) this.width=650; "Src=" https://app.yinxiang.com/shard/s12/res/22f6176c-9497-40b9-a959-f6af2a0f3cd5/1.jpg " class= "En-media" style= "Margin:.857412em 0px 1.286em;padding:0px;border:0px;height:auto;"/>

The game is an MMO end-trip, the Gateway's mission is to accept the client's connection, and then through the distribution strategy, the player is thrown into the gamesvr, then all the player's requests are sent directly to Gamesvr, handled by GAMESVR. Of course, the distribution strategy here is different from the normal Web server, the Web server will generally be made stateless server, that is, for the client request to reach which server is not related, can be processed, but the game server is mostly stateful, the general distribution strategy of the Web is to do a load balancing , as long as the overall pressure to ensure that the server is a good architecture, but the game server due to the existence of state needs to maintain, so there is usually no way to do simple load balancing. For example, since we are MMO games, so there is a concept of the map in the server logic, like World of Warcraft game of different players born map is not the same, and you from a map offline, the next time you go online location will generally be your last offline location, According to the game history and planning to create a game effect, the game in the different maps between the pressure is usually not the same, such as the main city of the player is usually more than a remote field map players, and the game server pressure is usually seen in the player gathering, such as the pressure of a lot of IO. So from the designer's point of view, the general will be different maps assigned to a separate process, so gamesvr will usually follow the map to divide, then the gamesvr process is born with its own state, because two gamesvr process is not the same, the player is in which map, You can only throw players to which gamesvr up. Of course, this is only one of the practices we have taken, and others have different approaches, but they are broadly similar.

I've been thinking about that game. The load capacity of individual gamesvr, usually around 1000 people have already begun to tighten, this is also better understand, according to this server's architecture, almost all of the player logic is processed within the same process, only some common logic is assigned to the relay process processing , the relay process here takes two roles, one is to do the communication between different gamesvr, and the other is that it will also maintain the public logic in the game, what is public logic? such as chatting, gangs, leaderboards, and so on, these are not related to the map of the game logic, but also by a number of gamesvr shared parts are pumped out to the relay process, in fact, there are two approaches, one is to let each gamesvr process themselves to maintain the public logic, But it is clear that this will waste the GAMESVR process with only a few pressure loads left. But put logic into the relay process also brings some problems, such as in the game development will find that more and more logic needs to put into the relay process, resulting in the relay process more and more large, such as our game gang data and global timer maintenance by the relay process to maintain, But the programmer in the writing function often directly an RPC to use relay function, because it is very convenient, and from the design of the existing architecture is also reasonable, our then relay RPC interface design is synchronous interface, so when the RPC surge, the entire game logic card.

Relay's huge two problems, one is the probability of a single point of failure to become higher, and the other is that relay performance will cause the entire game server card change. Our server has a period of time at about 10 o'clock every night to start the card, as long as the public logic involved in the part of almost no use, such as unable to chat, no gang operation, and so on, the final troubleshooting results found that some of the functions of the game to write logic on the relay, A very complex calculation was made at 10, which caused relay to block there and was unable to respond to requests made by GAMESVR. I was in the end of the development of the game to join the project, when the volume of relay is still relatively small, we are deliberately to avoid the game logic on the relay, but when the game really entered the operating period, deadline limit, we have to put the logic relay, Because this is the quickest way to implement it. I watched the relay step-by-step, and as I left the project, the code on the relay was everywhere.

Let's talk about other parts of the architecture, such as bishop, which is used to perform statistics and validation of our in-game trading data, primarily with the company's trading system, and Accoutsvr's role is to handle the related operations of in-game accounts, such as setting up accounts, creating new roles, etc. Its main role is to ensure the uniqueness of the game data, such as the unique role name, pet name, and so on. Then the MySQL part, the cloud wind once said in the blog game server database function should be just an alternative,http://blog.codingnow.com/2014/03/mmzb_db.html In other words, if there is an ideal game server, never down, never maintenance, then in fact, the database is not needed, the database is a game recovery and fault tolerance mechanism, I very much agree with Yunfeng this argument, and once do not need to consider the database part, then game design actually lost a lot of fault-tolerant practices. The part about the database I'll talk about later.

Then is the extensibility of this architecture, for the game server, there are usually three kinds of extensions, one is Kanikai, the other is a suit, and finally is due to the server pressure to extend the logic process. Above our end of the server module from the design is not to consider the mechanism of the new service, a single set of server architecture support only one zone, so when Kanikai, the practice is to deploy the same set of server architecture, using the address of the client update server to achieve different service architecture; Because the design does not consider the multi-service design, so the data between the different services can be said to be irrelevant, then in the merger of the server there must be some conflicting data to deal with, not only some player data, and even some game logic data, such as I have done a function, is to achieve a full-service player league, In the end, each zone will produce a champion, and then the statue of the champion will be placed in the main city of the game for one months, but then there are two districts that have merged, so who is to show the statue, because no matter which area you show, the player will be dissatisfied, of course, this kind of thing usually need to be planned to consider and then , there is a real need to address this particular area. In conjunction, another problem is that the previously guaranteed role name duplication is the use of the respective area of the accsvr, usually accsvr to ensure the uniqueness of the practice is to use the same database to save the information that needs to be discharged, but for different network operators, the database is probably not unified, so that, When two of the different networks in the region need to be merged, there is a difficult problem, such as we once the telecommunications and Netcom's two areas of the merger, originally the two districts can indeed ensure that the role name is unique, but when the cross-carrier merger will find conflict.

Then the server pressure, do not know is because the person who designed this architecture did not consider or there is no such problem, so the ability of the server scale-out is very weak, for the new copy, the relay process will be based on the pressure of Gamesvr to choose the new copy on which GAMESVR process , but for the resident map, it is written dead in the configuration table, binding fixed gamesvr, and relay does not provide the ability to dynamically add gamesvr, which leads to a single server process pressure during the server run, in addition to restarting the server, there is almost no way. This exposure in the operating period is obvious, because the GAMESVR according to the map, when the Kanikai, when the player influx of the same map, resulting in a single gamesvr pressure peaks, but this time there is no way to dynamically expand the process of sub-pressure, and cause the server to be down. This is not uncommon in later operations.

Later I heard a lot about the page tour of the architecture, the page tour server as a whole is similar to the end of the idea, because the client's usual mode of communication is no longer the same as the end of the original TCP connection, but the use of HTTP and other short-connected protocols, so the client connected part of the design more flexible, And most of the game Logic of the page tour is not as complex as the end of the tour, in the case of the client's limited expressiveness, basically the overall game server design to be more streamlined, so I see the usual server backend will be more emphasis on how to scale. Above I mentioned the problem of poor architecture extensibility, compared to the page tour of the rolling mode, reflected the most obvious.

This is about my last game server look like, the next article started my own server design.

This article is from "rookie surfaced" blog, please be sure to keep this source http://rangercyh.blog.51cto.com/1444712/1673922

What am I thinking when I design a game server? (1)