What's the best server infrastructure for real-time games? [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

I'm developing a Real-Time game which should hold thousands of players in real-time. What would be the best server structure for this?

My idea was using 2 server clusters - one for the Server End (all the computing side) and one for the Database end, where a load balancer is "responsible" for each of the clusters. One main server will receive the requests from the users and send back the IP address of the relevant server that the user can work this.

The database cluster will use database replication for consistency between开发者_如何学Python the databases.

I'm using .NET + MSSQL for the game.

Thanks!

(P.S - Asked on ServerFault, no one could help :( )

---

Servers:

More information is needed to make any kind of suggestions. Thousands is a huge range, it could be 2000, it could be 200,000. Likewise the amount of data and processing you require form the servers will make a difference. If there will be lots of data, and integrity is important, it might be better to have a storage area network (SAN) for you app and database servers.

Networks:

Thousands of users sending lots of data is quickly going to cause network connection issues. If this is internet based you'll need multiple connections (just to handle the data, as well as for failover), if it's LAN based you may still need multiple "external" IP points. Internally (behind any load balancers/firewalls) you may also need to subnet things out since inter server communication may be quite high.

Backup:

What happens if one server goes down? Do users of that server get disconnected? Is their progress lost? If it's an app server, perhaps nothing is lost (as long as it's using database for all session data) but what about a database server?

Final Size:

Do you really want to design for a final size now? Designing the software and architecture now for a scalable setup is a great idea. If it's scalable (for example starting with: 1 connection, 1 app server and 1 db server) you can always modify the infrastructure as required (more users - add a load balancer and a second app server). As long as you designed with this in mind you should be able to scale out as things grow.

Total Tangent (AWS):

If you're not tied into something yet, and it's an online system, could you perhaps build off Amazon Web Services? Not only does their setup allow scalability, but they have some excellent cases studies on how to split up tasks/design your layout. Given AWS services are typically an analog of real-world servers, you can even take the case studies as a guide to building a non-AWS setup.