Для "распараллеривания" процесса обхода сайтов в любом случае требуется либо очередь, либо гипервизор.
И то и то, Вам придется "поднимать" на любом языке.
Да, в пайтоне это несколько проще из коробки. Но и пых не стоит на месте, сейчас такие задачи на нем решаются без особых костылей, чуть-ли не нативно.
iMaximus: разве хранение таких данных не позволяет использовать индексы? Вполне позволяет.
Но вот работать так с данными в реляционной БД - кощунство, нужно использовать соответствующие инструменты для своих задач.
В данном случае - связь *-to-many
Нет, почитайте про балансировку нагрузки (nginx + fpm).
Поднимается приложение сразу на нескольких серверах, и обслуживают запросы пользователей одновременно.
Естественно, БД, кэш, сессии, контент - все хранятся на отдельном компьютере.
Метрика - имел ввиду система анализа работы приложения, типа pinba.
Нагрузочное тестирование можно сделать тут loader.io
Относительно 5к rps - если это сайт, который очень хорошо написан, в плане оптимизации, то думаю справится 3-5 нод средней конфигурации. На одном компе - маловероятно, если это, конечно, не hello world :)
Но, реальность такова, что сейчас даже для 200 rps порой ставят 7-8 нод...
Для начала расскажите, какие текущие проблемы есть у Вашего решения?
Что происходит? Куда упираетесь? В каком месте задержки/лаги?
Есть ли какая-то система метрики аппки в целом?
Давать совет просто "как ускорить работу чата на сокетах" особо смысла не имеет.
Вики, новостями и планировщиком задач Вы перестанете пользоваться через пару месяцев, если не раньше.
Совет, который Вы не просили, и который проигнорируете, не заморачивайтесь за эти вещи. Делайте хороший софт, а все что вы перечислили "появится" само, если будет реально нужно.
Используйте блокировки на уровне базы данных (в mysql это допустимо для таблиц InnoDb).
Сваливается запрос на получение, первым делом смотрите завершена ли игра.
Если нет, то
стартуете READ COMMITED транзакцию, и читаете строку игры/раунда с флагом FOR UPDATE.
Это даст 100% гарантию, что только один запрос получит блокировку на эту строчку, остальные будут ждать (вплоть до таймаута) пока первый запрос отпустит (комит/ролбэк) нужную строку.
При получении блокировки проверяете её статус еще раз - если игра/раунд еще не завершен - проводите розыгрыш, делаете комит, отдаете резалт.
В противном случае сразу отдаете резалт.
Я Вам и дал ответ - проводите процесс розыгрыша в ином треде.
Либо используйте блокировки, чтобы только один тред проводил розыгрыш, дабы избежать race condition.
Свободное место есть, значить кэш инвалидируется при изменение самих данных.
Учитывайте, что любая модификация строк в таблице (update/insert/delete) сбросит весь кэш для этой таблицы