#azure #scheduled-tasks #azure-table-storage
#azure #запланированные задачи #azure-table-storage
Вопрос:
У меня есть таблица в хранилище таблиц Azure со строками, которые регулярно обновляются различными процессами. Я хочу эффективно отслеживать, когда строки не обновлялись в течение определенного периода времени, и вызывать генерирование оповещений, если это происходит.
Большинство реализаций планировщика задач, которые я видел для Azure, функционируют, гарантируя, что только один работник будет выполнять заданную работу одновременно. Однако настройка запланированной задачи, которая ожидает n минут, а затем запрашивает последнюю временную метку, чтобы определить, следует ли предпринять действие, кажется неэффективной, поскольку работа не будет распределена между работниками. Также, как правило, неэффективно опрашивать так много записей.
Примером использования этого может быть отправка электронной почты пользователю, который не заходил на веб-сайт в течение последних 30 дней. Предположим, что количество пользователей является «большим числом» для целей создания эффективного алгоритма.
Есть ли у кого-нибудь какие-либо рекомендации по стратегиям, которые можно было бы использовать для проверки недавних действий, не заставляя выполнять работу только одного работника?
Ответ №1:
Сохраняйте таблицу LastActive с меткой времени в качестве rowkey ( DateTime.UtcNow.Ticks.ToString("d19") ). Обновите его, выполнив пакетную транзакцию, которая удаляет старую строку и вставляет новую строку.
Теперь запрос для неактивных пользователей выглядит примерно так from user in LastActive where user.PartitionKey == string.Empty amp;amp; user.RowKey < (DateTime.UtcNow - TimeSpan.FromDays(30)).Ticks.ToString("d19") select user . Это будет достаточно эффективно для таблицы любого размера.
В зависимости от того, что вы собираетесь делать с этой информацией, вам может потребоваться поместить сообщение в очередь, а затем удалить строку (чтобы оно не было замечено при следующей проверке). Теперь несколько работников могут извлекать эти сообщения из очереди и выполнять действия.
Я смущен вашим желанием сделать это на нескольких рабочих экземплярах… предположительно, вы хотите воздействовать на неактивного пользователя только один раз, поэтому вы хотите, чтобы проверку выполнял только один экземпляр. (Затем работа по отправке электронных писем или что-либо еще, что вы делаете, может быть распределена с помощью очереди, но эта начальная проверка должна выполняться только одним экземпляром.)
Комментарии:
1. Я использовал пользователей как простой пример. Мои данные фактически обновляются раз в пять секунд для каждой строки. Обновление дополнительной таблицы приведет к значительно большим накладным расходам, чем простое сканирование таблицы по нескольким тысячам строк. Обычно вы также правы в том, что я могу просто поставить в очередь фактическую работу, которая должна быть выполнена, чтобы избежать чрезмерной загрузки одного работника. Однако, учитывая, что количество очередей ограничено ~ 500 сообщениями в секунду, работа, скажем, с 5000 строками займет 50 секунд для постановки в очередь. Я надеялся как-то обработать напрямую.
2. Что еще более важно, поместив все эти строки в один и тот же PK, я бы также ограничил количество обновлений / сек, которые я могу сделать, до 500. Я хотел бы быть масштабируемым до тысяч.
3. Если сканирование выполняется быстрее, то, наверное, я не понимаю, о чем вы спрашиваете. Выполните сканирование. Если один раздел недостаточно масштабируемый, используйте несколько разделов. Если одна очередь недостаточно масштабируема, используйте несколько очередей. Если вы сталкиваетесь с ограничениями для всей учетной записи хранилища, вы можете использовать несколько учетных записей хранилища или рассмотреть другую технологию хранения.