Вы хотите, чтобы один и тот же игровой сервер был доступен на кластере машин. Первый шаг, который вы сделали, это нормально: сделать базу данных доступной для репликации на удаленных компьютерах. Однако важно, чтобы вы проектировали весь игровой сервер слоями. Пусть игровой сервер сам по себе будет собственным приложением, собственным пакетом. Затем создайте отдельную базу данных. Эта база данных может быть фрагментирована, реплицирована на нескольких компьютерах.
Таким образом, вы можете создать слой доступа к данным для вашего игрового сервера, на котором он будет использовать API уровня доступа к данным для доступа к вашей базе данных на удаленной машине или локально. во время работы без сбоев в обслуживании. Нехорошо иметь каждый экземпляр игрового сервера со своей собственной схемой Mnesia, если вы не уверены, что данные, которые будут находиться в этой базе данных, не будут связаны: {local_content,true}.
Безопаснее иметь одинаковую схему Mnesia (она есть на вашем уровне хранения данных), реплицированную на несколько компьютеров. Тогда у вас есть хорошо спроектированные столы. Раскройте API в модулях, которые управляют вашими игровыми данными. Отсюда начните строить уровень доступа к данным (
<b>NOTE: Am talking of the 3-tier Logical Architecture, the Physical Architecture can take any form as long as it caters for Hardware and Network Failures.</b>). На уровне доступа к данным построен отказоустойчивый доступ к узлу базы данных. Методы, которые вы здесь указали, отвлекут уровень Application (Business Logic) от решения проблем с подключением, делая удаленные вызовы процедур для узлов базы данных e.t.c. Кроме того, эти методы должны быть способны обнаруживать ошибки «узел недоступен» и могут во время выполнения повторить вызов к другому узлу реплики базы данных без того, чтобы игровые серверы заметили это вмешательство.
Уровень доступа к данным может выполнять балансировку нагрузки на узлах базы данных путем эффективного мультиплексирования вызовов приложения к базе данных между узлами базы данных (зависит также от доступности и механизма переключения при сбое).
Хватит с этим разговаривать ....
В любом случае, краткое изложение того, что я изложил, заключается в том, что важно, чтобы вы отделяли Mnesia от своих игровых серверов. Делая это, вы можете управлять приложением-сервером в одиночку, а позже также беспокоиться о доступе к данным отдельно. Отделение вашей физической и логической структуры базы данных от других частей вашего проекта повысит гибкость и доступность. В будущем вы сможете изменить дизайн и вещи базы данных без изменения уровня доступа к данным. Вы даже можете переключиться на другую СУБД, такую как Riak или Membase Server в будущем, не изменяя свою игровую логику.
Другое дело: избегайте копирования схем здесь и там. Проектируйте реплицированную / распределенную архитектуру базы данных с самого начала. Не заставляйте игровые серверы копировать схемы mnesia с узла на узел, чтобы стать кластером. Пусть игровой сервер беспокоится об игровой логике и прочем, а слой доступа к данным - об игровых данных.
Некоторое просветление там, я надеюсь, это поможет. Успех!