Веб-сервисы или общая база данных для (игрового) взаимодействия с сервером? - PullRequest
1 голос
/ 14 мая 2010

У нас есть 2 серверных кластера: первый состоит из типичных веб-приложений, поддерживаемых базами данных SQL. Вторые - это оптимизированные многопользовательские игровые серверы, которые хранят все данные в памяти. Оба кластера взаимодействуют с клиентами через HTTP (Ajax с JSON). Есть несколько случаев, когда нам нужно обмениваться данными между двумя типами серверов, например, отчитываться и сохранять результаты игры (в конечном итоге они должны попасть в базу данных).

Мы рассматриваем несколько подходов к межсерверной связи:

  • Просто делитесь базами данных MySQL между кластерами (вводите SQL на игровые серверы)
  • Обмен данными в распределенном хранилище значений ключей, таких как Memcache, Redis и т. Д.
  • Используйте технологию RPC, такую ​​как Google ProtoBufs или Apache Thrift
  • Использование веб-служб RESTful (например, игровой сервер будет отправлять обратно на веб-серверы)

В данный момент мы склоняемся к веб-сервисам или просто делимся базой данных. Совместное использование базы данных кажется простым, но мы обеспокоены тем, что это добавляет дополнительную память и новую зависимость для игровых серверов. Веб-сервисы обеспечивают хорошее разделение проблем и соответствуют существующему Ajax, который мы используем, но добавляют сложность, накладные расходы и множество других способов обрыва связи.

Есть ли другие веские причины не использовать тот или иной подход? Что было бы легче масштабировать?

Ответы [ 2 ]

2 голосов
/ 14 мая 2010

Совместное использование БД приносит очевидный недостаток, заключающийся в отсутствии одного элемента для управления данными, поступающими в БД. Это может быть большой проблемой, поэтому я бы порекомендовал создать прикладной уровень.

Если этот уровень приложений является тем, что формируют ваши веб-приложения, то я не вижу ничего плохого в реализации взаимодействия клиент-сервер между игровыми серверами и веб-приложениями. Позвольте игровым серверам передавать данные на уровень приложений и заставлять их подписываться на обновления. Это хорошо подходит для системы очередей сообщений, но вы можете избежать создания собственной системы, основанной на REST, например, если она лучше соответствует вашей текущей архитектуре.

Если веб-приложения не образуют прикладной уровень, я бы предложил ввести такой слой, написав небольшое приложение, которое скрывает специфику хранилища. Каждая сторона получает дескриптор интерфейса приложения и записывает в него данные.

Чтобы обмениваться данными между двумя системами, прикладной уровень мог бы затем использовать распределенную БД, такую ​​как mnesia, или внедрить многоуровневую систему кэширования с репликацией. Самой простой версией этого будет репликация, запускаемая по времени, например, с MySQL, как вы упомянули. Другими параметрами являются очереди сообщений, реплицируемая память (терракота) и / или реплицированные кэши (memcached), хотя они не обеспечивают постоянное хранение.

0 голосов
/ 15 мая 2010

Я бы также посоветовал посмотреть на Redis как хранилище данных и с пометкой для распределенного pub-sub.

Хотя Redis - это хранилище K / V в памяти, в последней версии есть поддержка виртуальных машин, в которой ключи хранятся в памяти, но значения могут быть выгружены, когда давление памяти достигает настраиваемого порога. Он также имеет встроенную простую репликацию master-slave и публикацию подписки.

NodeRed построен на node.js , который является масштабируемым и смехотворно быстрым js-сервером на стороне сервера.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...