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

У меня есть очередь Azure servicebus с включенным сеансом. Мне нужна какая-то форма службы, которая может читать из очереди, обрабатывать их и сохранять результат (в памяти для последующего извлечения). В нашей текущей архитектуре мы используем лазурную сервисную фабрику. У меня возникло несколько вопросов относительно того, какой из них выбрать сервис с отслеживанием состояния или без отслеживания состояния.

Если я использую службу с отслеживанием состояния, то, исходя из документации, которую я понимаю, служба будет работать на 1 первичном узле (при условии, что 1 раздел) и 2 активных вторичных узлах. Это означает, что если у меня есть кластер Service Fabric из 10 узлов, то эта служба с отслеживанием состояния будет в первую очередь использовать только один узел (VM).

Поэтому, если я добавлю слушателя к этой службе с отслеживанием состояния для чтения сообщений из очередей, тогда эта служба на основном узле будет читать сообщения из очередей, а все остальные 9 узлов не смогут использоваться. Это верно?

Если я использую службу без сохранения состояния, я могу создавать экземпляры на всех 10 узлах, и все они могут прослушивать сообщение в очередях и обрабатывать их параллельно. Однако я потеряю возможность сохранять результаты.

Пожалуйста, порекомендуйте.


azure-service-fabric azure-servicebus-queues service-fabric-stateful
person Sai    schedule 27.01.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Поэтому, если я добавлю слушателя к этой службе с отслеживанием состояния для чтения сообщений из очередей, тогда эта служба на основном узле будет читать сообщения из очередей, а все остальные 9 узлов не смогут использоваться. Это верно?

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

Если я использую службу без сохранения состояния, я могу создавать экземпляры на всех 10 узлах, и все они могут прослушивать сообщение в очередях и обрабатывать их параллельно.

Точно. Службы без сохранения состояния могут выполнять свою работу параллельно, и состояние не сохраняется. Это также причина того, что для этой модели Service Fabric нет надежной коллекции.

Однако я потеряю возможность сохранять результаты.

Не обязательно верно. Вы по-прежнему можете сохранять свои данные в централизованной / общей БД, как и раньше с решениями без сохранения состояния (например, облачными службами или веб-приложением Azure).

Вам следует спросить себя, какую проблему вы решаете. Если у вас есть сегментирование данных, Statful имеет больше смысла. Если у вас нет сегментирования данных и / или вам нужно увеличить вычислительную мощность, а не масштабировать, то лучше использовать Stateless.

person Sean Feldman    schedule 27.01.2018
comment
Спасибо, Шон, я стараюсь избегать записи результатов во внешнее хранилище (задержка и обслуживание). Я думал, что могу использовать функцию служебной фабрики для сохранения результатов в памяти для последующего использования. Похоже, мой лучший вариант - придерживаться режима без сохранения состояния для обработки очередей и создать еще одну службу с отслеживанием состояния только для хранения / получения результатов. Есть ли в этом смысл или я слишком усложняю? - person Sai; 28.01.2018
comment
Имея в виду надежные коллекции SF, имейте в виду, что их следует использовать только в качестве горячих данных. И как горячие данные, они должны храниться в холодном хранилище для целей резервного копирования / восстановления на случай, если что-то пойдет не так. - person Sean Feldman; 30.01.2018