Каково максимальное количество экземпляров субъекта для заданного идентификатора субъекта для данного субъекта в любое время в кластере Service Fabric?

Я пытаюсь понять максимальное количество экземпляров идентификатора актера, которые будут выполнять данный метод (на данном интерфейсе актера) в любое время в данном кластере фабрики служб. Вот мой пример:

  1. Допустим, я только что определил класс актора с именем CustomerActor, который является производным от актера сервисной фабрики и реализует интерфейс ICustomerActor, который имеет единственный метод с именем Process.
  2. Допустим, у меня есть клиент, который отправляет сообщение методу ICustomerActor.Process, используя идентификаторы акторов на основе идентификатора клиента. В этом примере мой диапазон идентификаторов клиентов находится в диапазоне от 1 до 99. Следовательно, мой диапазон идентификаторов актеров — от «Клиент/1» до «Клиент/99».
  3. Предположим, что CustomerActor настроен с количеством разделов = 9 и количеством узлов = 3, что означает, что на узел может быть 3 раздела.
  4. Предполагая одинаковое распределение идентификаторов акторов клиентов по всем разделам, давайте предположим, что раздел 1 будет обслуживать идентификаторы клиентов от 1 до 99/9 = 11, раздел 2 будет обслуживать идентификаторы клиентов от 12 до 22 и т. д.
  5. Давайте предположим, что кластер работает нормально с равномерным распределением, и для целей этого обсуждения не происходит сбоев узлов.
  6. Теперь внезапно клиент начинает отправлять несколько запросов (в быстрой последовательности) для определенного идентификатора клиента (по какой-либо причине), скажем, Customer/8, который находится в разделе 1, и предполагает, что кластер в настоящее время обслуживает только запросы customer/8. .
  7. Допустим, клиент только что отправил 20 запросов на актера с идентификатором Customer/8. За исключением этого идентификатора субъекта клиента, в кластере нет другого трафика.
  8. Допустим, клиент может отправлять все вышеперечисленные запросы (без блокировки на стороне клиента), потому что мы используем напоминания в классе CustomerActor, которые немедленно возвращают управление обратно клиенту.

Вот мои вопросы:

  1. Поскольку модель актора гарантирует однопоточное программирование, будет ли только один экземпляр CustomerActor (сопоставленный с идентификатором актора: Customer/8), который выполняет метод ICustomerActor.Process во всем кластере? Если да, значит ли это, что в очереди может быть максимум 19 запросов (при условии, что 1-й запрос еще не завершен)?

  2. Или будет 3 экземпляра (по одному на узел) CustomerActor (все сопоставлены с идентификатором субъекта: Customer/8), которые одновременно выполняют метод ICustomerActor.Process во всем кластере? Если да, значит ли это, что в очереди может быть максимум 19/3 запросов (при условии, что 1-й запрос на любом узле еще не завершен)?

  3. Или будет 9 экземпляров (по одному на раздел на всех узлах) CustomerActor (все сопоставлены с идентификатором субъекта: Customer/8), которые одновременно выполняют метод ICustomerActor.Process во всем кластере? Если да, значит ли это, что в очереди может находиться максимум 19/9 запросов (при условии, что 1-й запрос в любом разделе еще не завершен)?

  4. Или есть другое поведение, которое я не учел?


person Raghu    schedule 01.08.2016    source источник


Ответы (1)


  1. Есть один экземпляр одного Actor с одним идентификатором. Actor доступ действительно является «однопоточным доступом», поэтому запросы ставятся в очередь. (этот ответ, как это работает)
  2. Субъекты размещаются внутри ActorService (службы с отслеживанием состояния), которая имеет первичную и вторичную реплики. Сами акторы не имеют понятия первичное/вторичное. ActorID определяет раздел ActorService, в котором он размещен.
  3. Данные распределяются по служебным разделам, поэтому нет.

больше чтения:

person LoekD    schedule 01.08.2016
comment
Так вы говорите, что (1) в моих вопросах есть правильный ответ? - person Raghu; 01.08.2016
comment
Да, при условии, что запросы отправляются только в Customer/8. - person Vaclav Turecek; 01.08.2016