На самом деле ничего не существует для приложений с малой задержкой и высокой пропускной способностью в памяти, таких как онлайн-игры в реальном времени, по крайней мере, не как часть произвольного промежуточного программного обеспечения.
Проект Darkstar предпринял замечательную попытку сделать это с точки зрения удобства использования и сложности, но обнаружил (что неудивительно), что это не масштабирование.
В конечном счете, это сложная (хотя и неразрешимая) проблема, когда нет решения, близкого к универсальному. В частности, вы, вероятно, будете иметь компромисс между необходимостью действовать с устаревшими игровыми данными, с одной стороны, и необходимостью постоянно обмениваться общими данными, с другой стороны. Отсутствие правильности и экспоненциальный рост сложности ... выберите свой яд.
Стоит отметить - особенно если домен вашего приложения не является играми в реальном времени - что вы часто не возражаете, если работаете с устаревшими данными, если они скоро станут правильными. В таких случаях удобны простые системы кеширования, такие как memcache. Точно так же, если вам нужно больше корректности, но вам не нужно слишком беспокоиться о пропускной способности, может подойти что-то вроде Hazelcast (упомянутое в другом ответе), но для большинства онлайн-игр, которые достаточно велики, чтобы требовать балансировки нагрузки, тысячи операций / sec "просто недостаточно хорош.
Некоторые технологии MMO делают некоторую попытку распределить приложение путем его географического разделения, что означает, что на самом деле не так много общего состояния, и требует, чтобы эта схема имела смысл в игровом мире и художественной литературе.
Другой подход состоит в том, чтобы разделить его по сервисам и реализовать большинство сервисов с вашим любимым стандартным подходом RPC. Это позволяет вам легко масштабировать, если ваши сервисы независимы, но любые зависимости между сервисами возвращают вас на круги своя.