Какую архитектуру выбрать для бэкенда мобильной онлайн игры?
Вечер добрый!
Все мы знаем, что существует куча ситибилдеров для различных мобильных платформ. Везде необходимо совершать какие-либо действия через заданный промежуток времени. Гугл подсказывает много инфы о том, как надо собирать кластер, как лучше разбить на таблички бд, о том, что сюжет — это главное в игре. Но молчит как рыба о том, как реализовать правильно эти самые таймеры ожидания. После предыдущих вопросов к хабру и своих размышлений, нарисовалось несколько вариантов:
1) Хранить в бд время окончания, и время от времени дергать сервак
2) Использовать встроенные в node.js таймеры, если верить описанию api, то будь их хоть 1кк все должно быть ок(?)
3) Redis+Resque — кажется очень простым в реализации решением, но не нашел инфы, насколько это целесообразно(экономично)
4) RabbitMQ — там вроде можно организовать доставку сообщений after delay, что кажется очень гуд, учитывая его хорошую масштабируемость
Какой вариант лучше? Может подскажите, где можно почитать, про мою задачу? Или, возможно, даже есть опенсорсные примеры? Вроде как должны быть и готовые библиотечки или фрэймворки под это дело, ведь таких игрушек миллионы, сложно поверить, что каждые пишет свою реализацию?!
Проект в стадии глубой беты. Но надеемся на большое число клиентов, те неограниченно большое. Будем одновременно выпускаться под несколько платформ, поэтому рост пользователей скорее всего будет лавинообрахным, те времени на переделку после запуска же точно не будет.
1) теоретически можно, но не проще ли выделить сервер времени на базе NTP + JSONP API к нему?
2) node.js умирает уже при более 50таймерах, т.е. в принципе работа возможна, НО высокоточное время 100% не получит (писал проект — ЗНАЮ, ms точно потеряеете, а при большом числе клиентов погрешность до 10s может быть)
3) а почем не MemcacheDB + MemcacheQ = БД + Очереди
4) RabbitMQ самое то — особенно хорош в failover режиме
Memcached+q — при мерно тоже самое, что и редиска со спасателем, причем оба заявляют, что самые быстрые и крутые=)
Кролик и мне пока нравится больше всего, но не работал с ним. И почему-то мне кажется, что если мы познакомимся поближе, проблем много будет с ним. Хотя не знаю. Было бы опять же таки здорово где-нибудь прочитать, про использование его таким образом, все-таки это не его основное назначение.
так скажем, чисто для контроллера можно и потерпеть. если конечно Вы настолько неперевариваете синтаксис erlang — то можете написать свой велосипед контроллер на node+crond
> 2) Использовать встроенные в node.js таймеры, если верить описанию api, то будь их хоть 1кк все должно быть ок(?)
Если сервер упадет, то у вас слетят все таймеры.
3) Redis+Resque — кажется очень простым в реализации решением, но не нашел инфы, насколько это целесообразно(экономично)
Отличное решение, если не нужна максимальная производительность.
У вас вопрос больше по теме «Как и где хранить список задач?» или я не так понял?
Можно мой вопрос примерно так и сформулировать.=) если честно Resque юзал максимум для того, что подсветку кода в бэкграунде делал, с этим он справлялся великолепно. Что понимать под максимальной производительностью? Просто было ьы здорово почитать про то как он себя ведет, если в очередь 1кк задач запихнуть.
Почему вы зациклены на 1кк? Это всего лишь 1кк записей вида вызови такую функцию с такими параметрами в такое время… т.е. просто 1024 * 1024 * 10-50 (размер записи) = 10-50mb данных. Вы лучше скажите, какая максимально допустимая погрешность выполнения события?
Средний
