Server Load balancer-key to implementation of large-scale online systems (Part II ))

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.
　
The best server program can be designed, and the access traffic of a single program is limited. In the face of a large and growing network user group, how can we make our architecture adapt to the massive user access in the future, this
Naturally, the Server Load balancer problem is involved. 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. True
Positive 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 ".
The role is to step-by-step guide the client to the final bottom-layer server responsible for the real logic. We calculate the number of servers required for "millions of online, first, consider that the underlying logic server can
Number of client connections.
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, in this case, it may not be able to represent
The actual number of servers in the table, because in addition to the underlying servers, it also includes logon/account servers and Hall servers. However, due to login/account server and Hall server, they are connected to the client
These two types of servers are short connections (that is, after obtaining the required information, the client and the server are disconnected). Therefore, the pressure on these two types of servers is higher than that on the persistent connections (I .e: always connect the client to the server
It is much less, and their stress is mainly on Processing 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
When you log on to the server, the server is directly connected to the game room server and tries to play the game. Therefore, because the game room server and the lobby server and the login/account server both have the login targets for players
The game room server detects that the player has not logged on to the server to perform necessary account verification, so it will kick the player offline. From this point of view, data synchronization between servers is a real
Another necessary condition for Server Load balancer is now.
The data synchronization between servers also presents different implementation solutions based on different applications. For example, we are processing the gamer login question.
Question. 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 determines that the server is connected at the same time.
Does the player exceed the custom upper limit? If yes, the "Login Server Manager" (usually an internal server that is connected to the server and is not directly open to the player) apply for arbitration.
Server Manager "selects a new server IP address and port information based on the current load of each login server to send to the client. After receiving the IP address and port information, the client redirects to connect to the new server.
Log on to the 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 underlying logic server only stores
The user data on the server itself, it cannot find the user data on other servers. To solve this problem, a simple approach is to provide a global
List of players. 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, but the main function is to detect whether players have logged on repeatedly. However, if you want to use such a global list for some other applications, Data Synchronization becomes more complex. Ratio
For example, if we allow cross-server operations (such as cross-server combat and cross-server transaction) in the MMORPG of the ultra-large seamless map, data synchronization will become extremely complex, it is easy to make the processing logic unavailable.
Prediction.
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, not like the QQ leisure platform.
Similarly, all users have a centralized data storage point. MMORPG game data is stored separately based on different server groups. When a player logs on to a QQ game, the QQ game-related server automatically
Server Load balancer is used for player logon. a server that is relatively busy performs user verification for the server and allows the user to choose the game room to access. However, when a player logs on to MMORPG
Dynamic Server Load balancer is generally designed for players to choose which server group they want to enter. This is because the data in each server group is different. In fact, the MMORPG Server
The architecture idea is similar to the architecture idea of casual platforms. MMORPG's idea is that it can provide players with an unlimited independent game world (that is, server groups) to meet the needs of large players online; leisure Platform
The idea is: the game room can be opened infinitely for players to meet the needs of a large number of players online. These two applications can be infinitely used in "a complete game world". 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 as comprehensive as a casual Platform
Server connection is not acceptable, but it is necessary to solve many cross-server problems, such as friends, teams, and gangs, all of these player organization forms defined in traditional MMORPG
The rule may change because "all servers are 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!