Могу ли я читать/записывать от разных актеров с одинаковым идентификатором PersistenceId?

введение Akka.Persistence в блоге Petabridge дает понять, что вы не можете иметь несколько акторов с одним и тем же PersistenceId:

Поле PersistenceId важно — оно однозначно идентифицирует объект, сохраняющий свое состояние с помощью Akka.Persistence, и в любой момент времени для одного PersistenceId должен быть ровно один постоянный действующий субъект.

[...] так что представьте, что у вас есть два актера с одним и тем же PersistenceId, но разными порядковыми номерами, записывающими в одно и то же хранилище. Это будет хаос и неизбежные ошибки — поэтому крайне важно, чтобы каждый PersistenceId был глобально уникальным в вашей системе ActorSystem (по крайней мере, для всех акторов, пишущих в это хранилище).

Я могу придумать сценарий, в котором у вас будет два отдельных актора: один, который заботится о сохранении состояния персистентности в базе данных (т. е. вызывает Persist()), а другой воспроизводит сообщения из журнала, когда это запрашивается вручную (т. е. вызывает Recover()). . Операции чтения и записи будут выполняться разными субъектами. Только один когда-либо пишет, и только один когда-либо читает. Однако обоим нужен один и тот же PersistenceId.

Я считаю, что в этом сценарии должно быть безопасно, чтобы два субъекта использовали один и тот же PersistenceId. Но, учитывая приведенные выше предупреждения, есть ли причина, по которой такой подход может быть опасен на практике?


person Gigi    schedule 29.08.2016    source источник
comment
Для этого вы можете попробовать группу Google akka.net или канал чата gitter — основные участники там довольно активны. Ваше описание звучит нормально для меня, но я не знаком с akka.persistence, так что....   -  person tomliversidge    schedule 29.08.2016
comment
gitter.im/akkadotnet/akka.net   -  person tomliversidge    schedule 29.08.2016
comment
groups.google.com/forum/#!forum/akkadotnet-user- список   -  person tomliversidge    schedule 29.08.2016


Ответы (1)


Я могу представить сценарий, в котором у вас было бы два отдельных актора: один заботится о сохранении состояния персистентности в базе данных (т. е. вызывает Persist()), а другой воспроизводит сообщения из журнала по запросу вручную (т. е. вызывает Восстанавливаться()). Операции чтения и записи будут выполняться разными субъектами. Только один когда-либо пишет, и только один когда-либо читает. Однако обоим нужен один и тот же PersistenceId.

Требуемое поведение уже представлено как Persistent Actors и Постоянные представления. Из документов:

В то время как постоянный субъект может использоваться для создания и сохранения событий, представления используются только для чтения внутреннего состояния на их основе. Подобно постоянному действующему лицу, представление имеет PersistenceId для указания набора событий, которые должны быть повторно отправлены в текущее представление. Однако это значение должно быть соотнесено с PersistentId субъекта, который является производителем событий.

Изменить: обновлено, чтобы предоставить больше информации о том, как получить доступ к событиям в постоянном представлении.

Вы можете загрузить из журнала, переопределив метод Receive объекта Persistent View. Аргументом для этого метода является объект, поэтому вам нужно будет привести этот объект к любому событию (событиям), которое вы сохранили через метод Persistent Actor.

Метод Receive также обрабатывает любые другие сообщения, которые вы передаете в представление, например. запрос на чтение с уровня представления. Я обычно сохраняю список событий внутри представления и возвращаю из них пользовательскую модель представления.

protected override bool Receive(object message)
{
    // if the message is a previously persisted event, update our internal list
    var e = message as MyEvent;
    if (e != null) _events.Add(e);
    return true;

    // if the message is a request for a view model, read from our list of stored events
    var r = message as ReadRequest;
    if (r == null) return false;
    Sender.Tell(new ViewModel(_events));
    return true;
}
person Chima Osuji    schedule 30.08.2016
comment
Хороший. Поддерживают ли постоянные представления загрузку из журнала (как при Recover())? Док, кажется, упоминает только снимки. - person Gigi; 30.08.2016
comment
@Gigi - обновил мой ответ парой комментариев о доступе к событиям в постоянном представлении. Надеюсь это поможет - person Chima Osuji; 31.08.2016
comment
Выглядит как интересный подход к кэшированию. Спасибо, что поделился! - person Gigi; 31.08.2016