Thoughts on large-scale Multiplayer Online Systems

 

A major focus of current Internet applications is the huge number of users, which brings many challenges to server development and design. Here I would like to talk about my thoughts and experiences on these issues. I have a lot of contact with large-scale multiplayer online systems. There are several types of systems: 1. p2P systems, P2P live broadcast software, may encounter the problem of hundreds of thousands or even millions of people watching popular programs at the same time. Due to the special nature of P2P, generally, user information is not maintained in a unified manner. All the server needs is to provide the node source for P2P customers and provide tracker services for P2P customers to find other P2P nodes. Therefore, when dealing with large numbers of online users, P2P simply needs to add tracker and field source. This kind of Multiplayer Online is the least one that needs to be considered during software design. 2. online game server system. The online game server can solve this problem by isolating the entire user space into N worlds, such as a server in a certain area of MMO or a room in casual games. When the number of users increases, you only need to constantly Add Server groups and room servers. The only trouble lies in the unified authentication and economic system of a user. Because these two blocks have little load and the logic is relatively simple, the implementation is not very difficult. 3. The problem with the IM system is that its entire user space is completely unified and cannot be isolated by zone server or room. When the number of online users on the IM Server exceeds, it is imperative to design a cluster system. At this time, a single Logic Server and a single database cannot meet the performance requirements of the system. Data and services must be distributed across physical servers and managed in clusters. When the number of concurrent users is below 1 million, one of the methods I designed is to use one or more servers similar to the MySQL proxy to access the database in the background. Data in the DB is stored in segments by digital account or by hash algorithm. The front-end Logic Server does not directly deal with DB. Instead, the database is accessed through the DB proxy, which ensures that the database's storage policy is not transparent and can be changed independently in the logic part of the foreground. The foreground Logic Server, you don't even need to know the table structure of the database. You only need to send a request to query and result sets with the specified conditions in the DB proxy request. When the number of logical servers is less than 1 million online simultaneously, the number of logical servers is not too large. These logical servers can be directly interconnected. Each Logic Server is responsible for the logical processing of a digital account, and each Logic Server notifies other servers of its own number segment range. When a request is not processed by the server, such as sending text messages to users on other logic servers, the request can be directly forwarded to other logic servers. DB proxy is at the front end of the DB server. The processing capability of a single dB proxy is limited after all. You may need to configure a DB proxy for each database server. Each of the front-end logic servers shares a DB proxy. IM system with frequent database access. Implementing database cache in the IM system is very helpful for performance improvement. The front-end Logic Server should also cache data as much as possible to reduce the number of visits to dbproxy to improve the overall system performance. In order to direct the client to the specified Logic Server, the front-end must have a dispatch server to provide the address and port of the logic server. Before connecting to the logical server, the IM Client must query the dispatch server to obtain the logical server address. To enhance flexibility, you can set up a central server ,. To dynamically provide configuration information such as logical server and DB proxy. And facilitate backend Management of server groups. The design here is for the udp im system. Tcp im system, high cost, less research. In actual application, some performance test data and operation data are required to obtain the optimized architecture.