Управление одновременным исполнением рабочих ролей Azure в нескольких экземплярах - PullRequest
9 голосов
/ 13 января 2011

У меня есть простая рабочая роль в Azure, которая выполняет некоторую обработку данных в базе данных SQL Azure.Рабочий в основном добавляет данные из стороннего источника данных в мою базу данных каждые 2 минуты.Когда у меня есть два экземпляра роли, это, очевидно, удваивается.Я хотел бы иметь 2 экземпляра для резервирования и время безотказной работы 99,95, но не хочу, чтобы они обрабатывались одновременно, поскольку они просто дублируют одну и ту же работу.Есть ли стандартный шаблон для этого, который я пропускаю?Я знаю, что мог бы установить флаги в базе данных, но надеюсь, что есть другой более простой или лучший способ справиться с этимСпасибо

Ответы [ 4 ]

7 голосов
/ 13 января 2011

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

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

0 голосов
/ 05 июня 2013

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

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

0 голосов
/ 14 января 2011

Семафора в том виде, в котором она была предложена, будет подходящим вариантом, хотя я, вероятно, пойду с простым биением времени в метке-хранилище.

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

0 голосов
/ 13 января 2011

Не существует супер простого способа сделать это, я не думаю.

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

Тем не менее, предостережение заключается в том, что произойдет, если один из экземпляров потерпит крах в середине обработкии никогда не выпускает семафор?Вы можете реализовать значение «тайм-аут», после которого другие экземпляры будут пытаться запустить процесс запуска, если не было разблокировки в течение периода времени X.

В качестве альтернативы, вы можете использовать стороннюю службу мониторинга, такую ​​как * 1007.* AzureWatch для отслеживания неотвечающих экземпляров в Azure и запуска нового экземпляра, если количество «готовых» экземпляров меньше 1. Это сэкономит, вы можете сэкономить деньги, не имея необходимости постоянно запускать и запускать 2 экземпляра., но есть небольшая задержка между тем, когда экземпляр выходит из строя и когда запускается новый.

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