StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Easy. The web servers, which are stateless, are load balanced. The application servers (middle tier), which hold the session data, are not. The web servers can use your session id cookie to determine what app server to contact.</p> <p>Memcached and Microsoft's Velocity are products that solve this exact need.</p> <p>Edit: How does a web server know which app server to contact? This is embedded into the session id hash, and could generically be done however you like. It could be as simple as your session id being server:guid. <a href="http://www.socialtext.net/memcached/index.cgi?faq#how_does_memcached_work" rel="nofollow noreferrer">Memcached</a> bases it off the hash, though.</p> <p>The important bit is that the client has to be able to figure out what app server to contact in a stateless fashion. The easiest way to do that is to embed it into the key, though a registry (perhaps on it's own tier) would work as well and could provide some fault tolerance. </p> <p>Edit2: Going back over <a href="http://se-radio.net/podcast/2008-09/episode-109-ebay039s-architecture-principles-randy-shoup" rel="nofollow noreferrer">some</a> Ebay <a href="http://www.infoq.com/interviews/shoup-ebay-architecture" rel="nofollow noreferrer">interviews</a>, I may have gotten the particulars of their implementation a bit wrong. They don't do caching, and they don't do state in the middle tier. What they do, is to have a load balanced middle tier (app servers) partitioned by function. So, they would have a pool of servers for, eg., viewing items. And then another pool for selling items.</p> <p>Those app servers have a "smart" DAL that routes to sharded databases (partitioned both by function and data, so Users A-L on Database1, Users M-Z on Database2, Items 1-10000 on Items1, etc.).</p> <p>They don't have state in the middle tier because they're partitioned by function. So, a normal user experience would involve more than 1 pool of app servers. Say you view an item (ViewAppServerPool), then go to bid on an item (BidAppServerPool). All of those app servers would have to stay in sync, which then requires a distributed cache to manage everything. But, their scale is so large that no distributed cache could effectively manage it, nor could a single database server. This means they have to shard the data tier, and any cache implementation would have to be split across the same boundaries.</p> <p>This is <em>similar</em> to what I posted above, just moved down a layer. Instead of having the web server determine which app server to contact, the app server determines which database to contact. Only, in Ebay's case, it could actually be hitting 20+ database servers because of their partition strategy. But, again, the stateless tier has some sort of rule(s) that it uses to contact the stateful tier. Ebay's rules, however, are a bit more complicated than the simplistic "User1 is on Server10" rule I was explaining above.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload