Minecraft faces a scalability issue: as the number of players increases, performance quickly degrades.
This is fundamentally a scaling problem. As more clients connect, the number of chunk loading requests rises accordingly. This forces the main game thread to manage an increasing number of Entities, BlockEntities, and BlockUpdates, while also handling more requests for generating Chunks that haven't yet been created.
The problem can be solved by distributing the load across multiple systems.
To address this, the system should follow these key principles:
-
Each server should be solely responsible for managing a specific section of the world.
-
The system must handle seamless player transfers between servers, without the client being aware of the change.
-
The client should continue to receive all game information as if connected to a single server, even though that data may be distributed across multiple servers.
The Minecraft world is dividen in a ring configuration, each ring is handled by only one server
Player and entities can seamlesly transfer between servers.
//GiF
The next image shows a wide view of the architecture of the solution.
The next graphs shows the mspt of 3 diferent loads with 3,5 and 11 load units in an ordinary server. Each load unit consists of an aproximation of a real player load on the server. (84 entities, 267 block updates y 5120 block entities). Notice how the 11 load excedes the 50ms and has TPS drop.
The new distributed system handles the same load across 11 Workers with no TPS drop.
