Стратегии проверки бездействия в Azure

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

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

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

Есть ли у кого-нибудь рекомендации по стратегиям, которые можно использовать для проверки недавней активности, не заставляя выполнять эту работу только одного работника?


azure azure-table-storage scheduled-tasks
person David Pfeffer    schedule 17.10.2011    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Сохраните таблицу LastActive с отметкой времени в качестве ключа строки (DateTime.UtcNow.Ticks.ToString("d19")). Обновите его, выполнив пакетную транзакцию, которая удалит старую строку и вставит новую.

Теперь запрос для неактивных пользователей выглядит примерно так: from user in LastActive where user.PartitionKey == string.Empty && user.RowKey < (DateTime.UtcNow - TimeSpan.FromDays(30)).Ticks.ToString("d19") select user. Это будет весьма эффективно для таблицы любого размера.

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

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

person user94559    schedule 18.10.2011
comment
Я использовал пользователей как упрощенный пример. Мои данные на самом деле обновляются каждые пять секунд для каждой строки. Обновление дополнительной таблицы привело бы к значительно большим накладным расходам, чем простое сканирование таблицы по нескольким тысячам строк. Как правило, вы также правы в том, что я могу просто поставить фактическую работу в очередь, чтобы избежать чрезмерной загрузки одного рабочего. Однако, учитывая, что очереди ограничены ~ 500 сообщениями в секунду, работа, скажем, с 5000 строками займет 50 секунд. Я надеялся как-то обработать напрямую. - person David Pfeffer; 18.10.2011
comment
Что еще более важно, поместив все эти строки в один и тот же PK, я также ограничу количество обновлений в секунду, которые я могу выполнять, до 500. Я хотел бы масштабироваться до тысяч. - person David Pfeffer; 18.10.2011
comment
Если сканирование быстрее, то, наверное, я не понимаю, о чем вы спрашиваете. Сделайте сканирование. Если один раздел недостаточно масштабируем, используйте несколько разделов. Если одна очередь недостаточно масштабируема, используйте несколько очередей. Если вы сталкиваетесь с ограничениями для всей учетной записи хранения, вы можете использовать несколько учетных записей хранения или рассмотреть возможность использования другой технологии хранения. - person user94559; 19.10.2011