Репликация акторов akka по узлам с отслеживанием состояния

У меня есть приложение Akka, которое я запускаю как веб-приложение с помощью Play Framework. Когда я запускаю это приложение, я создаю набор Актеров, у которых есть состояние. Эти субъекты реагируют на внешние сообщения и изменяют состояние (я изменяю состояние с помощью механизма context.become (...)).

Теперь я хочу запустить несколько экземпляров этого веб-приложения, чтобы обеспечить отказоустойчивость. Но проблема в том, что веб-приложение предоставляет конечную точку WebSocket, к которой подключается интерфейсное приложение. Затем я транслирую состояние экземпляра Actor каждые 4 секунды через конечную точку WebSocket в приложение Front End.

У меня здесь несколько вопросов:

  1. Как я могу запустить еще пару экземпляров моего веб-приложения Play Framework, имея в виду, что у меня есть акторы с отслеживанием состояния! Я хочу быть уверенным, что если один из экземпляров выйдет из строя, субъект с отслеживанием состояния в этом экземпляре будет воскрешен с состоянием, которое было перед его отключением. Подойдет ли Akka Cluster Sharding?

  2. Скажем, у меня в приложении 10000 таких акторов с отслеживанием состояния, как я могу использовать Akka Cluster Sharding, чтобы не все из этих 10000 акторов работали в одном узле? Я имею в виду, как я могу заставить первые 5000 участников работать на node1, а следующие 5000 - на node2? Прямо сейчас то, что я делаю с единственным экземпляром, заключается в том, что когда я запускаю свое приложение, я читаю базу данных и использую данные для запуска одного экземпляра актора для каждой строки базы данных.

  3. Как шаблон запроса работает с сегментированием кластера? Любые сообщения, которые я отправляю в Shard Region, будут перенаправлены на соответствующий экземпляр Actor, но как насчет запроса сообщений от определенного субъекта? Будет ли работать так же? Я прошу сообщение от Актера, я отправляю свой запрос в Shard Region, и этот сегментный регион пересылает это сообщение соответствующему Актеру? Это правильно?

Какие-либо предложения?

2
0
516
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Есть два разных способа настроить для этого кластер akka:

  1. Сделайте так, чтобы все ваши экземпляры Play Framework сформировали кластер, как вы предложили
  2. Настройте отдельный кластер akka (назовите его backend, если хотите) и используйте клиент кластера из экземпляров Play Framework для подключения и взаимодействия с вашим кластером.

В обоих случаях выше я бы использовал модуль сегментирования кластера для того, чего вы хотите достичь.

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

На ваши вопросы:

  1. Шардинг кластера позаботится о разделении ваших акторов на несколько запущенных экземпляров и перенесет их, когда экземпляры выходят из строя или повышаются. Кластерное сегментирование вообще не будет иметь дело с состоянием вашего актера. Это совершенно отдельная проблема, и поэтому я упомянул выше стойкость акка.
  2. Ключом к хорошему распределению ваших актеров при использовании сегментирование кластера является обеспечение хорошего extractShardId и достаточного количества шардов. Скорее всего, у вас не будет ровно 5000 акторов на узел, как в вашем примере, но это может быть достаточно близко. Я бы порекомендовал начать с большого количества шардов, намного большего, чем количество экземпляров кластера, которые вы планируете использовать, 100 - это нормально для начала. Это плюс хороший extractShardId примерно равномерно разделит вашу нагрузку между узлами кластера.
  3. Спросите работает нормально, то, что вы говорите, правильно. Система сегментирования использует комбинацию extractShardId и extractEntityId для маршрутизации вашего сообщения к правильному экземпляру актера. Затем этот актер может просто ответить на sender().

Заметки:

  • все вышеперечисленное также отлично работает через кластерный клиент.
  • в зависимости от того, что вам нужно, может не потребоваться запускать всех актеров с самого начала. Когда вы отправляете сообщение сегментированному субъекту, который еще не существует, этот субъект будет автоматически и прозрачно запущен системой сегментирования кластера. В это время вы можете восстановить его состояние. Это плюс автоматическая пассивация поможет вам сэкономить много ресурсов!

Состояние My Akka Actor не сохраняется, а находится в памяти!

joesan 12.04.2018 11:47

Рассматриваемое приложение - это потоковое приложение, в котором с правой стороны приложения у меня есть подчиненная система, которая является PowerPlant, а с левой стороны у меня есть фронтенд, который визуализирует состояние этого PowerPlant. Поэтому мне нужно запускать актеров с самого начала, когда мое приложение Play запускается!

joesan 12.04.2018 11:51

Говоря о силовой установке ... что вы ожидаете, если отключится электричество и ваши серверы отключатся, вы потеряете состояние? Как ты с этим справляешься?

Frederic A. 12.04.2018 12:38

Идея состоит в том, чтобы иметь возможность восстанавливать состояние, в котором оно оставалось, когда в момент отключения питания на одном узле. Таким образом, если один узел умирает, тогда все PowerPlant, которые были частью этого узла, должны быть восстановлены в своем старом состоянии в другом узле!

joesan 12.04.2018 12:49

И вы полагаетесь в этом на магию? В противном случае вам придется позаботиться об этом самостоятельно. Вот почему я упомянул постоянство акка ... А для перезапуска всех акторов в случае сбоя узла вам понадобится установить сегментирование кластера для запоминания сущностей

Frederic A. 12.04.2018 12:53

Я еще не думал о сохранении моего состояния Actor в каком-нибудь магазине, таком как Cassandra или MongoDB. Если сохраняемость Akka хорошо сочетается с сегментированием кластера, я бы определенно пошел на это!

joesan 12.04.2018 12:55

Основываясь на ваших предложениях, я смог набросать целевую архитектуру того, как я буду ее реализовывать, чтобы она масштабировалась! Вот картинка: github.com/joesan/plant-simulator/blob/master/IMG_0635.JPG

joesan 12.04.2018 12:56

Считаете ли вы, что набросок, который я сделал, достаточно разумный?

joesan 12.04.2018 13:03

Да, это соответствует тому, что мы сказали выше

Frederic A. 12.04.2018 13:04

Прохладный! Спасибо за ваш вклад!

joesan 12.04.2018 13:05

Другие вопросы по теме