[vworld-tech] RE: databse usage
hook_l at pyrogon.com
Wed Feb 11 11:21:37 PST 2004
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.
All communication is done via TCP, so whether these reside on
different machines isn't particularly relevant except for
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
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.
More information about the vworld-tech