Необходимо реализовать мультиплеер для нескольких настольных и мобильных онлайн игр. Игры разработаны на HTML5/JavaScript/ActionScript 3. Никакой сверхсложной синхронизации и риалтайма на стороне сервера не нужно. Так как игры относительно простые (например, дурак/нарды/шахматы/балда), то нужно реализовать что-то вроде игровых комнат/столов с количеством игроков от 2 до 10-15 (не больше) + текстовый чат.
В каждой игровой комнате один из игроков делает какое-нибудь действие/ход, а все остальные должны ждать в это время + должна быть общая синхронизация (обновление) между игроками так, чтобы каждый игрок в комнате увидел у себя, как походил текущий активный игрок и что произошло в это время. Также необходимо реализовать контроль входа/выхода игроков из комнат.
Главные требования - максимальная простота, возможность масштабирования и высокие нагрузки. Не хочется создавать еще один велосипед с использованием UDP/сокетов на C++/Java. На данный момент решение вижу следующим образом. Основная информация о пользователях (логины/пароли/баланс/уровень и т.п.) будет хранится в БД MySQL+репликация на несколько серверов. Вся информация о игровых комнатах будет хранится в in-memory хранилищах типа Redis (для быстроты доступа). Данные от клиентов будут приходить через протокол HTTP в виде JSON. Для обработки HTTP запросов будет NGINX + PHP/Python. Клиенты будут обновлять игровое поле/комнату/стол регулярно отправляя на сервер запросы к API (возможно Long Polling). Сервер будет проверять состояние игровой комнаты в Redis и обновлять состояние/передавать управление/ход следующему игроку.
Посоветуйте, пожалуйста, как более правильно реализовать все это с точки зрения архитектуры/оптимизации нагрузки на сервер и масштабирования. Понимаю, что полностью готового решения нет, поэтому буду рад услышать любые советы/ссылки/фреймворки/библиотеки/опыт других людей для менее болезненного написания сервера.
Особенно интересен опыт разработчиков мультиплеерных социальных и мобильных игр (не Unity3D).
Приоритетные языки и технологии: HTML5, JS, AS3, MySQL, Redis, Memcached, PHP, Python, Java.
Если Вы говорите, что часть клиентов уже сделана на html5/JS, то вообще самое простое будет взять: socket.io и поднять сервер на nodejs с тем же socket.io только в качестве сервера. Данные также в БД + кэш рэдиса. Особенно больше ничего и не надо.
+ посмотрите в сторону ionic framework, позволяет обернуть web-приложение в нативное на мобильные платформы, если игры не нагружены анимацией, то вполне достойный вариант.
И в итоге получается Вам надо сделать 1 клиент на js+socket.io, на веб просто загрузить его, а на мобилках обернуть в ionic. И сделать сервер, который будет создавать комнаты и принимать новые подключения.
PHP плохо подходит, так как в нем довольно больно реализовать нормальное взаимодействие через сокеты/long-polling для работы с комнатами.
Интересно сколько примерно игроков/игровых комнат может теоретически выдержать такой сервер одновременно (для небольшой карточной игры типа Дурак). Например, на небольшом VPS сервере c конфигурацией 1 GB RAM, 1 Core CPU 2.6 GHz, 20 Gb SSD, Ubuntu 14.04 x64.
Проблема не столько в выборе инструментов, сколько в разработке архитектуры, способной на горизонтальное масштабирование.
Нет никакой особой сложности сделать задуманное на php/python и даже perl взаимодействие через (веб-)сокеты. Преимущество node.js разве что в асинхронной работе с хранилищами из коробки, но это не означает еще, что сразу будет быстрее.
От себя бы порекомендовал использовать не MySQL, а PostgreSQL. Надежнее и как минимум не медленнее.
БД надо сразу шардировать. Как минимум шарды под пользователе-зависимую информацию.
Скорее всего также придётся написать прокси для раскидывания юзеров по разным гейм-серверам.
В общем, по хорошему нужен хотя бы сениор с опытом боевого геймдева.
Если речь идет действительно о большом масштабировании, то см. в сторону микросервисной архитектуры.
SQL плохо масштабируется горизонтально (добавлением серверов).
Рассмотрел бы отказ от MySQL в пользу MongoDB, например, она умеет горизонтально масштабироваться.
Рассмотрел бы отказ от БД вообще в пользу Tarantool. Если оперативной памяти хватает держать всю БД в ней, то это радикально быстрее.
Клиенты будут обновлять игровое поле/комнату/стол регулярно отправляя на сервер запросы к API (возможно Long Polling).
В наше время это не круто и по ресурсам в том числе. Я бы рассмотрел вариант websocket для новых клиентов и long polling для старых.
Средний
