High-performance MMORPG general server engine design-> basic concept 2

 

Book connection back

 

Last time, we divided the responsibilities of server groups into front-end servers, scenario servers, login servers, data servers... etc.

Logic-Service Logic-service DB-Service

|

-----------------------------------

|

Scene Manager

|

-------------------------------------

|

Front server front Server login server

|

Client client

However, after thinking, I found that this structure is a bit problematic.

What's the problem? After analyzing the game logic, we will find that the server logic of the entire Mmorpg is actually a response to server events. There are two types of events here, one is to change the attributes of the player (for example, to switch the skill and put it into the bucket), and the other is to change the attributes of other players, or you need to notify other players of attributes changes (such as attacking the other party, returning blood, changing clothes, and moving), that is, we analyze the events that occur in the scenario in the previous article, the second type of events far exceeds the first type of events, and most of the business logic also occurs in these events, so the processing of such events requires more CPU. In this case, the pressure on the front-end server is mainly I/O, and the pressure on the Scenario Server is mainly on the CPU. If the pressure on the front-end server is deployed separately on different machines, the pressure on the servers on both sides is not balanced. The front-end servers have a lot of CPU remaining, and the CPU of the server is insufficient in the scenario. So I decided to merge the two parts again, synthesize the logic service, and then run multiple logic services in parallel.

All the game logic is computed in the logic service, but according to the MMORPG business, all the logic is basically distributed according to the scenario, at this time, I faced two more difficult choice questions. The first solution is that we can organize the logic according to the scenario. For example, server A is responsible for scenario 1, 3, and 7, and server B is responsible for scenario 2, 4, and scenario 6, because the number of people in different scenarios is not average, in some scenarios, there are many people (for example, the location of the boss in a city where a large number of people are chasing), and in some scenarios, there are few people (for example, in the novice village after a period of operation ), in addition, hot scenes in the game are dynamically changing, and will change with the development of the game process. In this case, we need a Scenario Management Service, which is used to monitor each logic service and migrate other scenarios in the service where the hotspot scenario is located to the idle Logic Server. This logic must be supported by the client and soft switching of the server is required. Another way is to randomly distribute the logic of the scenario to all logic servers. The connections between scenarios are transmitted through messages, A Message Server provides a broadcast group for all scenarios to distribute messages. In this way, multiple message servers will come out. The first of the two solutions is the least latency for a single player. However, if the Scenario Management is poor, the distribution of CPU resources may be uneven, in addition, the scenario capacity is limited by the processing capacity limit of a single process. The latency of the second scheme must be greater than that of the first scheme, but the capacity of the scenario is not affected by the computing capability of a single process, and the scalability is better.

 

Finally, I decided to use python to implement this idea. First, there are a variety of basic frameworks to choose from, such as using high-performance gevnet or eruasia as the basis of TCP server. Second, python is dynamic, so you don't need to embed another dynamic language to adapt to the changing business logic. Third, python is a dynamic type, which is more convenient to Implement Message Service. I was planning to use Erlang, but I am not very familiar with OTP for the time being. so I will leave it for the time being. However, if I use the second method, I may use Erlang to implement the Message Server.

 

The next chapter goes directly to the implementation stage, and I will get this stuff out in any way. If no company is willing to spend money on it, I will get it out of Open Source in my spare time.