[vworld-tech] RE: databse usage

[Brian Hook]

On Wed, 11 Feb 2004 12:18:08 -0600, Patrick Dughi wrote:
> Is someone willing to post a generic top-to-bottom system design
> that could be (assuming it's workable) used by both small
> developers and the guys batting in the big leagues?  

Here's what we do, but the scalability is unproven.

LOGIN SERVER
ZONE SERVER
WORLD SERVER
DB SERVER

All communication is done via TCP, so whether these reside on 
different machines isn't particularly relevant except for 
CPU/memory/disk contention.

LOGIN SERVER takes incoming connections, character selection, then 
hands that off to the WORLD SERVER.

WORLD SERVER takes player and character info, looks up appropriate 
zone, then hands off to ZONE SERVER.  WORLD SERVER is also responsible 
for directing traffic between ZONES and doing world-wide events like 
broadcasts.

ZONE SERVER handles all mobs, events and actions within a zone, and 
directly communicates with the player.

DB SERVER(S) store, retrieve, process and report all data back to all 
other servers.  The LOGIN/WORLD/ZONE servers also have their own set 
of scripts; DB SERVER does not run any scripts at all.

Load balancing can occur anywhere you can split up server tasks.  
Multiple login servers can easily be done if you have a front-end that 
cycles through different login servers (this is probably rarely needed 
except for VERY high capacity servers where multiple worlds with 
thousands of players each are being served by a single login handler).

Splitting the duties of a single world server isn't as trivial, but 
obviously introducing new worlds is a simple/crude but effective way 
of load balancing.  Same for ZONE servers -- make more zones and 
appropriate servers and voila, you're good to go.

The DB is a bit trickier.  If you remove any dependencies between 
tables, you could probably have several different DB servers that 
service different types of actions.  The simplest mechanism is just 
mass replication -- a DB server for each zone/world and then a 
replication mechanism so that they stay synchronized.  All edits to 
static data are done an edit server which then propagates to the 
master server which then propagates to all the child servers.  If the 
master server is solely responsible for handling data that is written 
back then the architecture becomes a lot simpler, since static data 
changes propagate in one direction, and dynamic data changes don't 
need to propagate at all to the replicated servers.

More elegant solutions exist, I'm sure, but this seems eminently 
workable if a bit brute force.

Brian