sda писал(а): ↑2017.01.10, 02:55Проблема то в монге, она не может атомарно ничего изменить
Может. Об этом написано выше.
sda писал(а): ↑2017.01.10, 02:55поэтому ни в один момент времени нет гарантии, что снапшот, который снимается с базы находится в консистентном состоянии.
Неясно, что вы называете снапшотом и о какой консистентности ведёте речь. Но навскидку спрошу: а кто умеет? Разве MySQL умеет какие-то "консистентные снапшоты" возвращать с базы? Мне казалось, что как раз-таки у монги куда больше возможностей по целостной обработке коллекций документов (гарантирует неизменность коллекций во время применения к ним функций).
sda писал(а): ↑2017.01.10, 02:55Мне кажется я вообще пытаюсь сделать невозможное.
Именно. Куча требований без компромиссов: и надёжно, и быстро, и распределённо. Так не бывает.
sda писал(а): ↑2017.01.10, 02:55Походу реалтайм проекты никто не масштабирует.
Я до сих пор не пойму, что вы называете "масштабированием"? Можно масштабировать:
* вычисления - спрятать сервера под балансировщик
* кэш
* базу данных - шардить/реплицировать
* файловые операции - распределяя физические хранилища
Вы же говорите о каком-то сферическом "масштабировании" без конкретной задачи и профиля нагрузки. Где у вас затык? Что масштабируете?
Ну и если говорить про реалтайм-проекты, то там (как нигде в других местах) всё масштабируют: и кэши, и вычисления, и базы данных.
sda писал(а): ↑2017.01.10, 02:55Потому что если посмотреть любую онлайн игру, то везде куча отдельных серверов не связанных между собой и все имеют ограничение по количеству игроков на сервер.
Именно. Потому что важна целостная обработка данных в одной конкретной локации (или в одном мире). На этот мир обычно пишется какой-нибудь C++ демон, который крутит всё в памяти. Соответственно, все расчёты очень быстро происходят в памяти. А уже демон сам разруливает, когда и как ему осуществлять сохранение данных в БД на бэкенде. Соответственно, игрок делает какое-то действие, это действие в неблокирующем режиме разруливается демоном. Если ударить сервер по питанию, то часть игровых данных за последние N минут потеряется. Никаких таких надёжных решений (чтобы каждый ход сохранялся) не существует. Целостность обработки данных обеспечивается на уровне демонов (внутри него).
sda писал(а): ↑2017.01.10, 02:55Даже простейшая репликация базы в реалтайм проектах рожает кучу проблем. Кто-то обновил мастер и всем клиентам были разосланы обновленные данные по вебсокету, они обновили свой UI. В это время кто-то открывает сайт и читает начальное состояние с одной из реплик. Затем реплика синхронизируется с мастером, но UI клиента до сих пор со старыми данными. В итоге ничего толком не работает. Репликация работает для обычных сайтов по http протоколу, в парадигме запрос > ответ.
1. Даже в обычном http-сайте есть способы справиться с задержками репликации (некоторое время читать записанное с мастера, а не с реплик).
2. В таком виде реплику в скоростных реалтайм-вычислениях никто не использует. В реалтайм используют демоны, сообщающиеся между собой по сокетам.
sda писал(а): ↑2017.01.10, 02:55Поэтому я думаю, что распределенные реалтайм приложения сегодня - это похоже миф, чем реальность.
Опять же неясно, про "распределённость" чего и где вы говорите. Какая-то сферическая распределённость. Базы? Серверов? Демонов? Бывают ведь и многопоточные демоны - вот вам и распределённость. Но только она по потокам, а не по чему-то там.
sda писал(а): ↑2017.01.10, 02:55Похоже единственный вариант это возвращаться на рсубд и упираться в производительность сервера, на котором она крутится. Других вариантов, к сожалению, найти не получается. Чего только уже не пробовал.
Есть ещё второй вариант - найти наконец-таки профильную литературу по организации многоклиентских реалтайм-вычислений и посмотреть, что пишут эксперты этой области. Можно даже конкретно по играм найти книги с описанием типовых архитектурных подходов. А не пытаться построить своё решение на скорую руку.
Одно могу сказать точно: одним PHP вам не обойтись.
P.S.: в прошлом я работал в геймдеве. Тема очень сложная, даже форум по её исследованию вы выбрали неправильно. Как минимум, вам сюда:
https://www.gamedev.net/