0
У меня есть требование, когда я нажимаю свои ключи на redis с некоторым сроком действия. Также у вас есть абонент для прослушивания событий истечения срока действия ключа, а затем есть обратный вызов для моей другой системы, который может выполнять на нем некоторые бизнес-правила. Это хороший дизайн, чтобы иметь веру в redis pub-sub для этой утилиты? Средний TTL для ключей будет находиться в диапазоне ~ 15 минут.Использование redis pub-sub для истечения срока действия ключа
Использование другого дизайна позволит мне иметь планировщик/cron (каждую минуту) или некоторую систему опроса.
Спасибо Alok, вы можете помочь с еще одной штукой - в производстве у меня будет эта настройка на более чем 1 машине, где абонент будет работать на всех этих машинах. Итак, что может быть лучшим способом обработки одного и того же срока действия, чтобы я не вызывал другую систему больше, чем для истечения срока действия ключа? – Ankush
Вы имеете в виду настройку ведущего ведомого в производстве или кластер. В случае кластера это не будет проблемой, поскольку любой конкретный ключ будет храниться только в одном экземпляре. В случае установки ведущего/ведомого вы можете поместить подписчика для прослушивания событий только из основных экземпляров. –
Нет, я имел в виду, что подписчик будет в приложении Java, которое будет подписано на redis master expiry events. Теперь это приложение будет развернуто на нескольких компьютерах, поэтому события истечения срока действия будут поступать на все подписанные машины (так как все машины будут иметь одну и ту же упаковку и тот же код абонента). При получении этого события у меня будет обратный вызов для других систем, так как я могу обработать этот случай, когда я не отправляю обратный вызов со всех компьютеров, поскольку это будет повторение событий истечения срока действия. 1 способ заключается в развертывании приложения-подписчика только в 1 машине. Но что может быть лучшим? – Ankush