pax
у меня есть некий опыт написания серверов которые работают, потому расскажу всякое
сначала по терминам
PCU - Peak Concurrent user, грубо говоря сколько сокетов переварит ваш сервак
RPS - Requests Per Second, если обработка не упирается в цпу то это bandwidth/packet_size, при пакете в 5 кб и канале 100 мбит, RPS будет 2.5k (тысяч ! не миллионов)
1) собсно PCU это грубо говоря сколько сокетов может держать ОС, линукс сразу идет НАХ*Й, ибо говно там в сетевом стеке, берем FreeBSD, на всяких ерлангах одна машина (12 ядер, 128 гб рамы) тянет 2kk PCU
2) внизу сервер БД, замечательная штука да, а теперь представим что сверху у нас 100500 серверов, одновременно пытается играть 5 млн юзеров, везде что-то двигается, такая байда может нагенерить трафика на бд в районе 200-400 гб\s, можно конечно взять один йоба сервак, вставить туда 64 ядра, 512-1024 гб рамы и пидорасить тупо 10 ethernet карт по 40 гб\с, но это не выход =) а каналов по 400 гб\с щас ни у кого толком нету
выход это использовать горизонтально масштабируемую бд, разделить их использование по контексту, например база профилей игроков для статистики, база профилей персонажей и их инвертаря и квестов, для каждого сектора локации отдельная бд
плюс каждая бд должна бекапится, скажем если дядя дима прийдет к стойке с ломом и начнет пидорасить все серваки то хороший кластер должен это пережить, для этого используем взаимозаменяемые на лету серваки бд с полной репликацией
для такой цели я рекомендовал бы большинство серверов ставить NoSQL, например MongoDB, и делать там реплики по 3 сервера и обязательно покупать реалтайм бекап (
http://www.mongodb.com/press/10gen-a...backup-service мы этот юзаем, он бекапит журнал и потом можно восстановить любую точку во времени), но некоторые (статистика точно) должны быть SQL ибо к ним идут пидорские запросы наподобие "а дай мне топ 10 юзеров" который NoSQL не переваривает
3) авторизация и лобби, они ОЧЕНЬ топорные на логике, по-сути логики там нету, там даже не нужно постоянное подключение, это просто REST API, а если так то юзаем мощный веб-сервер, например Mongrel2 или NGINX, надо отдать должное этим монстрам и на среднем серваке они займут канал 10 гб\с полностью с всего ~10-25% CPU
думаю тут описывать сильно не надо, код авторизации тупо является посредником между веб сервером и бд, лучше всего его написать на C и вшить прямо в код веб сервера (в то место где он CGI делает)
делать балансер тут вообще нету смысла, разве что у тебя будет ОТДЕЛЬНАЯ СТОЙКА И ОТДЕЛЬНЫЙ СВИТЧ на это, единственный тип балансировки который взлетает на highload - ethernet balancing, то есть у нас N серваков у которых по две сетевые карты, одни карты торчат аплинком в мир, вторые карты торчат тупо в один лоу-латенси свитч, в этот свитч торчат все обработчики запросов, обработчики запросов тоже имеют по две карты (одна в свитч, другая аплинк), и когда на балансер приходит ip пакет с запросом то он у него меняет ethernet адресс ! таким образом наш чудо свитч по матрице комутации перекидывает пакет очень быстро, с помощью round-robin можно так забалансировать очень много трафика
4) сервера комнат, думаю надо банально ставить монстро-серваки по много ядер и много рамы, клиенты будут с ними конектится постоянно, потому тут всё зависит от контекста использования - ведь игровая логика бывает разная, всяким MMORPG надо коллизии считать например
этим серверам нужно кешировать состояния мира чтобы не лазить в бд иначе слишком сильно увеличится латентность обработки запросов
верх эволюции это горизонтальное масштабирование в рамках одной комнаты, но я такого не видел, например в EVE Online у них по серверу на звёздную систему, если в какой системе будет происходить бой то они вытягивают сервер помощнее из пула и запускают на нем эту систему
думаю можно это отдельно обсудить если скажешь какой жанр игр нужно =)