Сохранять субъект в качестве государственного или детского актера в Акке

Question

Рассмотрим вариант использования интернет-магазина, где у меня есть инвентарь и предметы. Я вижу несколько вариантов для моделирования этого с использованием актеров Akka.

1. Создайте постоянный актер с именем Inventory, сохраняя элементы в своем состоянии, например, в списке.

2. Создайте актера с именем Inventory, а затем дочернего персистентного актера для каждого элемента. Каждый предмет сохраняет свое состояние.

Вопрос в том, имеет ли смысл второй вариант? Когда я должен сохранять сущность как состояние актера или моделировать его как дочерний актер? Что мы должны принять во внимание в этом случае?

Answer 1

Насколько я понимаю, вариант 2 лучше.

1. В инвентаре может быть цена суммы (предметов), если цена предмета изменяется, вариант 1 не является хорошим выбор.

2. Если элемент является единственным действующим лицом, вариант 2 легко обрабатывать изменения, вызванные элементом.

Answer 2

Это может быть субъективно, я бы предпочел второй вариант.

• Это позволяет мне сузить свое мышление до одной маленькой проблемы, когда я нахожусь в роли этого детского актера, и я не думаю о более широкой картине при этом.
• Breaking таким же образом помогите тестировать логи c в отдельности, в дополнение к любым более крупным тестам
• Дочерний актер может быть убит и повторно создан, не затрагивая все остальные элементы
• Актеры дешевы, и миллионы могут быть созданы на типичном оборудовании
• Распределенные данные: в более сложном случае это может помочь вам масштабироваться по разным узлам. Например, у вас может быть кластер akka, в котором каждый узел кластера отвечает за подмножество сущностей (иначе говоря, sharding)

Когда я должен сохранять сущность как состояние актера или моделировать его как дочерний актер?

По моему личному опыту, когда у вас есть иерархическое состояние, а состояние 2-го уровня требует отдельных операций, имеет смысл создать дочерний субъект для каждого объекта 2-го уровня. Например:

case class Employee(Id, Name, Address)

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

Map[Id, Employee]

И если сообщения следующим образом: AddEmployee(Employee), DeleteEmployee(Id) тогда это не имеет большого значения. Но если они имеют вид: UpdateName(Id, Name) или UpdateAddress(Id, Address), тогда становится затруднительно управлять этими операциями на этой карте.