Диагностика субъектов Azure с отслеживанием состояния

Я все еще пытаюсь понять Субъекты Azure Service Fabric с отслеживанием состояния. Итак, мою (текущую) проблему лучше всего представить в виде такого примера:

  • У меня есть система службы поддержки, где каждый тикет — это актер с отслеживанием состояния. Актер знает о состоянии, в котором он находится (опубликовано, обработано, отклонено и т. д.), может получить доступ к связанным данным и все такое.
  • I find I have made a mistake and a bunch of those 50.000 tickets are in the wrong state. So, I need to
    • fix the code
    • опубликовать решение
    • исправить содержимое данных подмножества этих 50 000 актеров.

Теперь, как я могу запросить состояние этих актеров, например, «дайте мне каждого актера, который находится в состоянии «отклонено» и принадлежит пользователю, чье имя начинается с немецкого ümlaut»? Как я могу затем исправить данные состояния этих актеров?

Мне действительно нужно добавить метод запроса к каждому актеру и разбудить каждого отдельного актера? Или есть способ запросить эти словари состояний вне актеров, сидящих поверх них?


azure stateful azure-service-fabric actor
person Volker    schedule 11.04.2016    source источник
comment
Я предполагаю, что это касается Service Fabric?   -  person Richard Slater    schedule 11.04.2016
comment
Да. Вот эти: azure.microsoft.com /en-us/documentation/articles/   -  person Volker    schedule 11.04.2016
comment
я не знаю достаточно, чтобы помочь вам о ткани, но я рекомендую вам взглянуть на этого блоггера vunvulearadu.blogspot. com.ar это MVP с большим количеством постов, связанных с тканью и лазурью, я начинаю учиться отсюда   -  person Mariano Montañez Ureta    schedule 11.04.2016

Ответы (2)


arrow_upward
1
arrow_downward

Короткий ответ: да, в такой ситуации вам придется разбудить каждого актера (в конце концов).

Если вы уже находитесь в этом состоянии, я думаю, что предложение JoshL имеет смысл.

Чтобы избежать подобных ситуаций, вы можете хранить индексный словарь в службе с отслеживанием состояния, в которой хранится информация, которую вы хотите запросить, например. идентификатор актера и статус (опубликовано, обработано и т. д.). Затем вам нужно разбудить только тех акторов, которые имеют отношение к делу.

Для этого можно использовать два подхода:

  • Пусть служба с отслеживанием состояния направляет поток информации — отвечает за обновление индексного словаря и указание субъектам, что делать (например, изменить статус).
  • Назначьте субъектов, ответственных за уведомление службы с отслеживанием состояния об обновлениях состояния (это можно делать периодически, например, с помощью напоминаний).
person charisk    schedule 12.04.2016
comment
Вы знаете, все это довольно далеко от той легкости, с которой я могу сделать это с помощью решения на основе nbormal SQL: сделайте выбор, чтобы определить масштаб проблемы, напишите сценарий обновления, который исправляет ее в одной атомарной транзакции, запустите сценарий при развертывании нового кода актора. Не могу сказать, что я этому рад. Я имею в виду, что актеры параллельны и милы, и все такое, но ремонт вещей — это реальная жизненная ситуация, в которой они явно терпят неудачу. :-( - person Volker; 12.04.2016
comment
@Volker Мне самому это было интересно. Как разработчик, я получаю некоторое утешение от осознания того, что если я каким-то образом уничтожу все, по крайней мере, у меня останутся данные. С Актерами данные разбросаны по всему миру в небольших объектах, доступ к которым я могу получить только с работающей системой. Я все еще изучаю Azure Fabric, но надеюсь, что смогу прийти к некоторому пониманию передовых методов решения этой проблемы. - person Rick Love; 13.04.2016
comment
Хорошая точка зрения. Что происходит с состоянием актора с состоянием, если он умирает при активации? Я просто надеюсь, что его не удалят... - person Volker; 15.04.2016

arrow_upward
1
arrow_downward

Возможно, вы могли бы рассмотреть возможность переопределения OnActivateAsync в классе(ах) актора и реализовать там логику очистки, а затем обновить приложение SF?

Это предотвратит необходимость внешней итерации каждого отдельного экземпляра (поскольку среда выполнения SF будет вызывать для вас OnActivateAsync) и обеспечит выполнение логики для каждого экземпляра только в случае необходимости (только при следующей активации для данного экземпляра).

подробнее об активации/деактивации актера и т. д.< /а>

Удачи!

person JoshL    schedule 11.04.2016
comment
Так что, по сути, за время жизни продукта (вероятно, много лет) актеры получат большой хвост логики исправлений и проверки версий. Не могу сказать, что я в восторге от этого. Я начинаю задаваться вопросом, возможно ли а) получить доступ к хранилищу таблиц за актерами или б) использовать сервер sql в качестве поставщика хранилища. Или, может быть, вообще остаться без гражданства. - person Volker; 12.04.2016
comment
Я думаю, что есть поддержка пользовательских поставщиков состояний, так что это может быть вариант... хотя, вероятно, сложный. Помните, что важным преимуществом акторов с отслеживанием состояния является автоматическая репликация изменений состояния на все узлы в кластере. Маловероятно, что вы а) легко создадите сами или б) легко реализуете в пользовательском поставщике. Конечно, если вам это не нужно, то, возможно, лучший вариант - без гражданства. - person JoshL; 12.04.2016