2017-01-09 2 views
1

У нас есть несколько ключей Redis с заданным TTL, на которые мы хотели бы подписаться и принять меры после истечения срока действия TTL (планировщик задания la).Подписки подписчиков на ключи ключей Redis с использованием ServiceStack

Это хорошо работает в среде с одним хостом, и когда вы подписываетесь на ServiceStack, используя свой клиент Redis, до '[email protected]__:expired', эта служба будет выбирать его и принимать меры. Это фантастика ...

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

Я знаю, что уведомления о ключах не работают точно так же, как традиционные события pub/sub или messaging-layer, но есть ли способ выполнить какое-то подтверждение при таких событиях, чтобы в конце в день, только один хозяин продолжит эту задачу?

В противном случае существует ли способ отложить публикацию сообщений?

Спасибо!

ответ

1

Мое понимание вашего вопроса: вам нужно событие, основанное на unicast уведомление, когда ключ истёк.

Это решение будет полезно для вас, если это предположение верно. Это своего рода грубое решение, но работает!

Решение: Как-то вы должны использовать Список Redis/очереди и каким-то образом поставить истекшие ключи в списке Redis. Затем блокировка B * POP Операция в этом списке даст вам то, что вы хотите!

Как это работает? Предположим, что один фоновый поток будет непрерывно выталкивать истекшие ключи в список/очередь redis. Кластер экземпляров API будет вызывать блокировку pop в этом списке/очереди.

Поскольку блокировка поп-операции для каждого элемента списка redis будет потребляться только одним клиентом, только один экземпляр API получит уведомление об истекшем ключе !!!

Ref:

Список поп-операция: https://redis.io/commands/lpop

Аналогичная проблема с пабом/подразделами: Competing Consumer on Redis Pub/Sub supported?