Есть ли способ присвоения номера int различным экземплярам служб без сохранения состояния?

Question

Я создаю решение, в котором у нас будет (служба-структура) служба без сохранения состояния, развернутая в K экземплярах.Эта служба выполняет определенную рабочую нагрузку (например, запросы), и я хочу разделить рабочую нагрузку между ними как можно более равномерно - и я хочу сделать это динамическим решением, что означает, что если я решу перейти от K экземпляров к N экземплярам завтраЯ хочу, чтобы разделение рабочей нагрузки происходило таким образом, чтобы оно теперь автоматически распределяло нагрузку по N экземплярам.У меня нет каких-либо разделов, указанных для этой службы.

В качестве примера -

Допустим, я бы хотел запросить базу данных для получения определенного фрагмента записей.У меня 5 узлов.Я хочу, чтобы эти 5 узлов извлекали разные 1/5 набора записей.Это может быть достигнуто с помощью некоторой логики запроса, например (row_id% N == K), где N - общее количество экземпляров, а K - уникальное instance_number.

. Я надеялся использовать FabricRuntime.GetNodeContext().NodeId - ноэто возвращает guid, который не слишком полезен.

Я ищу способ, которым я могу определенно сказать, что это номер экземпляра M из N (мне нужно иметь возможность назвать экземпляры через 1..N) - чтобы я мог настроить свою логику запросов в соответствии с этим.Одно из требований заключается в том, что если этот экземпляр выходит из строя / падает и т. Д. ... когда SF автоматически перезапускает его, он все равно должен идентифицировать себя как один и тот же идентификатор экземпляра, чтобы 2 или более узлов не запрашивали один и тот же набор результатов.

Как лучше всего решить эту проблему?Есть ли решение, которое включает в себя чистую настройку через ApplicationManifest.xml или ServiceManifest.xml?

Answer 1

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

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

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

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

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

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

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

Что касается проблемы с идентификатором, можно указать InstanceId той реплики, на которой вы находитесь.StatelessService.Context.InstanceId это не последовательный идентификатор, а случайное число.Это лучше, чем использовать идентификатор узла, потому что у вас может быть несколько разделов на одном узле, и идентификатор будет конфликтовать друг с другом.Если вы решите использовать именованные разделы, вы можете вместо этого использовать порядок в имени раздела, чтобы у каждого раздела было последовательное имя.

Стоит отметить, что у сервисной фабрики есть ограничение, которое не делает 't разрешить службам иметь несколько реплик на одном узле , поскольку из-за этого ограничения вам, возможно, придется проектировать свои службы с учетом этого, иначе вы не сможете масштабироваться после достижения предела.Кроме того, в той же теме обсуждаются подходы к обработке нескольких распределенных элементов, которые могут дать вам некоторые идеи.