врят ли. там же специфика. вот решения некоторые можно использовать, а саму архитектуру. не. врят ли...
440Hz Игра внешне сильно похожа на поделки IT Territory (Astrum Online, а теперь Mail.Ru). Вы случайно с ними не заодно?
Padaboo Для соц. сети своя прослойка для обработки запросов и запуска модулей на стороне сервера. На стороне клиента организована прозрачная AJAX навигация с gracefull degradation (т.е. если JS нету - тоже навигация пашет - боты свободно бегают по открытым частям). Для остального пересел на Yii. Идёт хорошо, слазить не буду - будем набивать скилл.
Psih не совсем это имел ввиду, чутка попозже создам тему с 1001 вопросом, по кешированию и масштабированию
Да рецепт просто до банальности. * Хранить сессии централизовано, дабы не нарваться на то, что придётся юзеров привязывать к серверу (в моём случае - ArrayObject + memcache (а лучше memcachedb тогда уже - оно хоть перманентно)). * Не писать запросов, в которых over 9000 JOIN. Иногда лучше сделать 2 запроса, где делаете SELECT FROM WHERE, а потом SELECT FROM WHERE id IN(....). Особенно не стоит джойнить таблицы, к которым постоянно идёт доступ ото всюду. Банальный пример - таблица юзеров. * Не пихать слмшком много индексов, оптимизировать запросы и серебрянная пуля: использовать xtradb пока 5.5 не будет stable (хотя в нём всё равно есть такие вещи полезные, которых нету в официальной ветке - тут уж по ситуации). * Заложить интерфейсы по работе с данными, которые тагаются постоянно и везде, которые можно успешно кешировать с большой эфективностью. Опять пример - те же пользователи. Делим сперва на 2 селекта, второй селект оборачиваем в API и вуаля - нам обсалютно пофиг откуда и как делается выборка - скормили ID, получили массив юзеров. * Как ни странно - кормите сервер с базой оперативкой и не давайте базе разрастись за пределы оперативки по возможности. Т.е. нужно не тока добавить оперативку, но и не забыть увеличить буфер для иннодб и подтюнить остальные настройки. Если у вас начнёт не хватать памяти для актуальных данных - будете либо в жопе и срочно добавлять оперативку, либо пора начинать шардится. Последнее нужно предусмотреть зарание * И самое главное правило - пишите код правильно, закладывайте возможности маштабироватся, но не думайте об этом - слишком рано и возможно этим заниматься придётся через год-полтора-два Главное - что бы в голове был план действий, когда придёт время озаботится маштабированием.
а мы вынесли юзеров и все, что можно в демонов. храним и обрабатываем там уже готовые объекты а в БД сбрасываем по таймеру. тем самым БД не напрягается. демоны работают по HTTP, через nginx. т.е. вызывающий объект не знает где, что лежит. реализован полный РЕСТ, маппер, контроллер и т.д. гоняем только JSON. ну и много чего вкусного, но уже внутри геймплея. к примеру вот так одевается шмотка. PHP: <?php $aData = array (); $aData [ 'user_guid' ] = $aUser [ 'users_guid' ]; $aData [ 'inventory_guid' ] = $oHTTPRequest->get ( 'guid' ); $aData [ 'slot_id' ] = ( int ) $oHTTPRequest->get ( 'slot' ); $oResult = $oCommand->send ( 'user', 'POST', '/user/inventory/body', $aData , 'application/x-www-form-urlencoded' ); в демона летят ГУИД юзера и шмота. далее все происходит в демоне а ответом летят новые параметры юзера и чего там нам еще надо. Все это передается на клиента в JSON. на клиенте шмот перемещается на юзера и все. Юзер в демоне помечается как "измененный" и по таймеру все, что надо, ляжет в БД.
440Hz Как говорится - игры и социалки - две разные вещи Социалки по устройству ближе к простым сайтам, просто с хорошим расширяемым апи и иногда довольно замудрённые
асинхронные запросы появились в MySQLi начиная с 5.3. Вы его используете или своего клиента писали, как в том же phpD?
походу мы о разных вещах говорим? демон написан свой. с нуля. на php+libevent в самом демоне есть пул коннектов БД, и при необходимости из него выдается свободный коннект.
да, о разных. Вот код из примера phpD. Один воркер может одновременно обрабатывать много запросов. PHP: <?php $sql->query('SHOW VARIABLES', function($sql,$success) // то, что будет выполнено когда результат запроса будет "готов" { $sql->context->queryResult = $sql->resultRows; // save the result $sql->context->wakeup(); // wake up the request immediately }); то есть мы не пишем $result = $sql->query('SHOW VARIABLES'); , так как это будет выполняться не асинхронно и будет блокировать наш процесс.