Синхронизация ролей Azure - PullRequest
Новая
       9

Синхронизация ролей Azure

5 голосов
/ 31 августа 2011

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

Очереди Azure, похоже, не помогают в этом вопросе.Одним из вариантов является использование таблицы SQL с блокировками и хранимыми процедурами;но использование синхронизации sql в Azure кажется немного неловким.

Есть идеи?

Правка, моя подробная (но упрощенная проблема) следующая:

  • Есть n целей.
  • Единица работы должна быть выполнена для каждой цели через определенный интервал (скажем, 30 секунд - но она различна для каждой цели).
  • Iиметь м рабочих (размещено в ч экземплярах).
  • Обработка единицы работы может занять от 10 секунд до 1 часа.

Идея состоит в том, что у меня есть планировщик , который помещает единицы работы в очередь Azure, и каждый из m рабочих будет читать их и обрабатывать.

Проблема:

  • worker1 начинает работать на unit1 (что касается target1 ) - это займет много времени, скажем10 минут
  • 30 секунд прохода
  • планировщик выставляет еще одну единицу работы для target1 , скажем unit13
  • работник2 начинает работать на unit13 , против того же target1 - не хорошо

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

Ответы [ 3 ]

4 голосов
/ 07 сентября 2011

Я только что написал пару постов в блоге об использовании блоб-аренды для подобных вещей. См http://blog.smarx.com/posts/managing-concurrency-in-windows-azure-with-leases и http://blog.smarx.com/posts/building-a-task-scheduler-in-windows-azure.

2 голосов
/ 31 августа 2011

Даннри точен: очереди отлично работают для предотвращения работы нескольких экземпляров с одним и тем же рабочим элементом. Когда вы звоните GetMessage, полученное вами сообщение теперь невидимо для указанного вами промежутка времени (по умолчанию: 30 секунд). В этот промежуток времени никакой другой читатель не может получить это сообщение очереди.

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

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

0 голосов
/ 28 февраля 2013

CloudFX имеет класс PrimaryInstanceManager, который можно использовать для некоторых из этих сценариев.

...