использование очереди служебной шины Azure и BrokeredMessage.ScheduledEnqueueTimeUtc для возобновления подписок

Question

использование очереди служебной шины Azure и BrokeredMessage.ScheduledEnqueueTimeUtc для возобновления подписок

1

У меня есть модель подписки, и я хочу выполнить логику, связанную с возобновлением, например, выпуск нового счета-фактуры, отправку писем и т.д. Например, пользователь будет покупать подписку сегодня, а продление - через год. Недавно я использовал очередную Azure, и думаю, что он будет применяться для такого обновления.

Можно ли использовать Azure Queue, нажав сообщения, используя BrokeredMessage.ScheduledEnqueueTimeUtc (http://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.scheduledenqueuetimeutc.aspx) для таких долгосрочных запланированных сообщений?

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

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

Karl Cassar 13 нояб. 2014, в 18:03

Источник

Теги:

c#

azure

azureservicebus

azure-servicebus-queues

1 ответ

Ещё вопросы

b2zw2a · Answer 1 · 2014-11-13T16-33-00.000Z

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

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

Исключительно удивительный источник информации о лазурном обмене сообщениями

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

Управление версиями сообщений
Что происходит, когда вы хотите изменить Azure на что-то другое (AWS?)
Что делать, если вы решите изменить в следующем году Azure Service Bus для NServiceBus

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