Akka и состояние среди участников в кластере

Я работаю над своим проектом bc thesis, который должен быть сервером Minecraft, написанным на scala и Akka. Сервер должен быть легко развертывается в облаке или в кластере (не уверен, использую ли я правильную терминологию ... он должен работать на нескольких узлах). Однако я новичок в akka, и мне было интересно, как реализовать такую ​​вещь. Проблема Сейчас я пытаюсь понять, как разделить состояние между участниками на разных узлах. Моя первая идея заключалась в том, чтобы иметь актера Camel, который будет читать поток TCP от клиентов minecraft, а затем отправлять его в балансировщик нагрузки, который выбирает узел, который будет обрабатывать запрос, а затем отправлять некоторый ответ клиенту через TCP. Допустим, у меня есть реализующий субъект AuthenticationService, который проверяет, действительны ли учетные данные, предоставленные пользователем. У каждого узла будет такой субъект (или, возможно, несколько из них), и все субъекты должны иметь одинаковую базу данных (или состояние) пользователей все время. У меня вопрос, как лучше всего сохранить это состояние? Я придумал несколько решений, которые мог придумать, но я ничего подобного не делал, поэтому, пожалуйста, укажите на ошибки:

Решение №1: Сохранить состояние в базе данных. Это, вероятно, будет очень хорошо работать для этого примера аутентификации, где состояние представлено только чем-то вроде списка имен пользователей и паролей, но, вероятно, не будет работать в тех случаях, когда состояние содержит объекты, которые не могут быть легко разбиты на целые числа и строки.

Решение №2: Каждый раз, когда к определенному субъекту будет поступать запрос, который изменит его состояние, этот субъект после обработки запроса будет транслировать информацию об изменении всем другим субъектам того же типа, которые изменят свое состояние. состояние в соответствии с информацией, отправленной первоначальным актером. Это кажется очень неэффективным и довольно неуклюжим.

Решение №3: наличие определенного узла, служащего своего рода узлом состояния, в котором будут существовать субъекты, которые представляют состояние всего сервера. Любой другой актер, за исключением того, что у субъектов в таком узле не будет состояния и они будут запрашивать у субъектов в «узле состояния» каждый раз, когда им понадобятся какие-то данные. Это также кажется неэффективным и отчасти безупречным.

Итак, вот оно. Единственное решение, которое мне действительно нравится, - это первое, но, как я уже сказал, оно, вероятно, работает только в очень ограниченном подмножестве проблем (когда состояние может быть разбито на структуры Redis). Любой ответ более опытных гуру будет очень ценным. С уважением, Томас Херман