Какой вариант использования постоянного актера Akka?

Я запутался в применимости Akka Persistence и постоянных актеров, когда мне следует использовать постоянного актера?

Взяв, например, из модуля корзины данного приложения для покупок, будет ли сеанс корзины каждого пользователя постоянным действующим лицом с соответствующим уникальным идентификатором персистентности?

Каково удобство использования в реальных приложениях? Как сторона запроса обрабатывает состояние постоянного актора? Когда постоянный актор бесполезен в реальных приложениях?

Сохранение состояний или сохранение сообщений — это одно и то же? Разве нет? Какая разница, когда я должен использовать каждый из них?

Может ли кто-нибудь дать мне несколько примеров?


cqrs event-sourcing event-driven akka akka-persistence
person Alisson Vieira    schedule 15.03.2016    source источник
comment
Я считаю, что постоянные участники — это сторона записи в CQRS, и вам все равно нужно обрабатывать сторону чтения в каком-то хранилище с запросами. Актеры в Akka по определению являются источниками событий, поэтому я не вижу принципиальной разницы с любой системой, основанной на событиях, для обработки запросов (конечно, я понимаю остальные различия).   -  person Alexey Zimarev    schedule 17.03.2016

Ответы (1)


arrow_upward
7
arrow_downward

Это будет очень самоуверенный вопрос и очень самоуверенный ответ.

Представьте, что у вас есть система управления задачами, например. Джира или аналог. Допустим, у вас есть следующая раскладка актеров:

  • Project 1
    • Ticket 1
    • Билет 2
  • Project 3
    • Ticket 3

Если проекты и заявки на самом деле являются постоянными акторами, то по сравнению со стандартным подходом (запрос и т. д.) у вас есть следующие преимущества:

  • Включение и выключение актора восстанавливает его состояние, так что больше никаких сложных запросов и сопоставлений с кодом актора. Более того, если ваше приложение не работает, его перезапуск по существу загружает данные со всей историей (ниже)
  • Модель актора/надзор Akka дает вам дополнительный бонус - если ваш актор умер (т.е. задача умерла при попытке получить данные из внешней интеграции), перезапуск вернет его со всей историей.
  • История отслеживания уже есть (и вы можете смоделировать свои данные так, чтобы журнал событий фактически включал все данные об изменениях, такие как пользователь и отметка времени, а также старое значение/новое значение). На самом деле это применимо к огромному количеству областей бизнеса — например, к обработке сделок, где каждая сделка должна хранить свою собственную историю.
  • Другая часть — это запрос. Если ваша система в конечном итоге допускает согласованный дизайн, вы можете просто распределить данные по всем заявкам в проекте с помощью любого сложного запроса и дождаться ответов.

Полезность исходит из дизайна вашего приложения - некоторые из них хорошо подходят (например, несколько отдельных или слабо связанных объектов), некоторые не очень хорошо (например, вы хотите просто сохранить последний набор данных и создать предопределенный отчет о нем)

person abatyuk    schedule 16.03.2016
comment
О взаимосвязи между концепцией Билета и Актером. В этом примере у нас будет билет актера1, еще один билет актера2 и так далее? - person Alisson Vieira; 16.03.2016
comment
Правильно - IMO, лучшим кандидатом на то, чтобы стать PersistentActors, являются объекты с отслеживанием состояния в домене - билет / проект / торговля / что угодно. - person abatyuk; 17.03.2016
comment
Теперь я начинаю это понимать, так что приложение, основанное на актерах, такое как Akka, может быть составлено из миллионов актеров? Спасибо за ответы! - person Alisson Vieira; 17.03.2016
comment
Это даже лучше. Приложение Akka может иметь миллионы действующих лиц во время выполнения — до тех пор, пока у вас есть память. В случае с Akka Persistence у вас может быть буквально бесконечное количество актеров, поднимающих и опускающих их — с сохранением состояния в журнале событий. - person abatyuk; 18.03.2016