Server Load balancer-key to implementation of large-scale online systems (Part II) (design and selection of server cluster architecture)

 

Author: sodimethyl
Source: http://blog.csdn.net/sodme
Disclaimer: This article may be reproduced without the consent of the author, but any reference to this article must indicate the author, source and the declaration information. Thank you !!

In network applications, "Server Load balancer" is no longer a new topic. From hardware to software, there are also many ways to achieve Server Load balancer. The server Load balancer discussed here does not refer to Server Load balancer Based on DNS redirection or other hardware devices, but to Server Load balancer at the application layer.

Generally, it is necessary to introduce Server Load balancer in a large online system. How big is a system called a large system? For example, online games of hundreds of thousands at the same time, and Web applications of hundreds of thousands of concurrent online games can all be understood as large systems. This is a broad concept.

Well-designed serversProgramThe access traffic of a single program is limited. In the face of a large and growing network user base, how can we adapt our architecture to the massive access volumes in the future, this naturally involves the issue of Server Load balancer. The core architecture of a large online system supporting millions or more is how to allocate the "millions" of concurrent online requests to each individual server program. The real logic processing should be based on the final underlying server program (such as the game room server of the QQ game platform), and those servers that existed before that, they can all be called "Guides". Their role is to step-by-step guide the client to the final underlying Server responsible for the real logic, we calculate the number of servers required for "millions of online", and first consider the number of client connections that can be carried by a single underlying logic server.

For example, according to the above analysis of the QQ game architecture, assume that each server program supports a maximum of 2 million online users (assume that one machine runs only one server program ), how many servers are required to achieve a 1.5 million online volume? If it is a little simpler, it should be: 150/2 = 75. Of course, this may not represent the actual number of servers, because in addition to the underlying servers, it also includes logon/account servers and Hall servers. However, since login/account servers and Hall servers, their connections to the client are short connections (that is, after obtaining the required information, the client and the server are disconnected, the pressure on these two types of servers is much less than that on persistent connections (that is, the client and server are always connected). The pressure on these two types of servers is mainly on instant concurrent access.

"Short connection" is the basic means to achieve load balancing at the application layer !!! If the client is always connected to the login/account server and Hall server, the layered architecture will be meaningless, there is no way to fundamentally resolve the conflict between the increasing number of users and the limited number of servers.

Of course, the reason why short connections can be used and maintain normal game logic is that a large amount of data synchronization operations are performed between the server and the server where players cannot see it. If a player does not log on to the login server but directly connects to the game room server and tries to play the game, the logic maintenance for player logon is performed between the game room server and the lobby server and the login/account server, the game room server detects that the player has not been logged on to the server to perform necessary account verification, and it will kick the player offline. From this point of view, data synchronization between servers is another necessary condition for load balancing.

The data synchronization between servers also presents different implementation solutions based on different applications. For example, we are dealing with gamer login issues. First, we can open some default login servers (Server IP addresses and port information) to players. When a player connects to the current Login server, the server first checks whether the number of players connected at the same time exceeds the custom upper limit. If yes, apply for arbitration from the "Login Server Manager" (usually an internal server that is not directly open to gamers) connected to the server, the "Login Server Manager" selects a new server IP address and port information based on the load of each login server to send to the client, after receiving the IP address and port information, the client redirects to the New Login server to complete the subsequent login verification process.

One feature of this solution is that an external access interface is provided on the player-oriented side, while inside the server cluster, A "Server Manager" is provided to record the load of each login server in a timely manner so that the client can select a new logon interface to the client according to the policy when the client needs to redirect.

The advantage of using a distributed structure is that it can effectively share the pressure on the entire system. However, the disadvantage is that the index of global information will become more difficult, because each individual underlying logic server only stores user data on its own server, it cannot find user data on other servers. To solve this problem, a simple approach is to provide a global player list by an intermediary within the cluster. The global list can be directly placed on the "Server Manager" or stored in the database as needed.

For applications with relatively independent logic, there are not many opportunities to use the global list. The main function is to check whether gamers have logged on repeatedly. However, if you want to use such a global list for some other applications, Data Synchronization becomes more complex. For example, if we allow cross-server operations (such as cross-server combat and cross-server transaction) in the MMORPG of the ultra-large and seamless map, data synchronization will become extremely complex, it is easy to make the processing logic unpredictable.

In my opinion, the architecture of QQ games is reasonable for casual platforms, which can also be called the standard architecture of casual platforms. What is the general architecture of MMORPG?

MMORPG generally divides the entire game into several game world groups, each of which is actually a separate game world. The data of different groups is independent of each other. Unlike the QQ casual platform, all users have a centralized data storage point, MMORPG game data is stored by server groups. When a player logs on to a QQ game, the server related to the QQ game automatically performs Load Balancing for the player's logon, select a relatively busy server to perform user verification for it and finally let the user choose the game room to enter. However, when a player logs on to MMORPG, there is no such automatic load balancing. Generally, players choose which server group they want to enter, the reason is that the data in each server group is different. In fact, the server architecture of Mmorpg is similar to that of the casual platform. The idea of Mmorpg is as follows: an independent game world (server group) can be opened for gamers without limit to meet the needs of large gamers online. The idea of a casual platform is: game rooms can be opened infinitely for gamers to meet the needs of a large number of gamers online. These two applications can be infinitely used in the "game world with complete gameplay". For MMORPG, a complete game map is a whole "game world ", for casual platforms, a game room can be described as a "game world ". If Mmorpg is used as a casual platform, it is not impossible. However, it is necessary to solve many cross-server problems, such as friends, teams, and gangs, all the rules defined in the traditional MMORPG for these players' organizational forms may be changed because they are "all available.

The architecture selection is diverse. There is indeed no so-called architecture that can be called the best. It is suitable for the current project and not necessarily for another project. For specific applications, different architectures are selected flexibly. But there is one thing that can be said: no matter how you architecture, what you want to do is to implement as stable and efficient as possible with the simplest possible solution!

<Full text>

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/sodme/archive/2005/06/15/394576.aspx