У меня есть сервис с балансировкой нагрузки, который должен аутентифицироваться с помощью токена для стороннего приложения и запоминать токен в распределенном кеше (есть ограниченное количество сеансов, которые могут быть открыты одновременно, и я не хочу иметь по одному на каждый узел с балансировкой нагрузки, а не один) несколько звонков). Для этого я намерен использовать блокировку Redis с одним экземпляром, как описано здесь .
Обычным подходом для узла, который не может получить блокировку, является выполнение спин-блокировки (т. Е. Проверить, блокировка доступна каждые 100 мс, например). Теперь в моей ситуации мне действительно не нужна блокировка, а скорее токен, который должен быть установлен в кеше процессом, который первым получил блокировку. Подход с спин-блокировкой имеет некоторые недостатки: - дополнительная нагрузка на Redis / сеть; - дополнительная не пренебрежимо малая задержка, потому что мы ожидаем больше, чем необходимо
Я планирую решить эту проблему с помощью функции подписки в Redis следующим образом:
- проверить, доступен ли токен
- если нет: проверить, можно ли получить блокировку для открытия сеанса
- если блокировка недоступна: подписаться на жестко закодированный канал
- проверить, доступен ли токен (чтобы отследить редкий случай, если он был установлен прямо перед нашей подпиской)
- , если нет: дождаться сообщения на подписанном канале
Процесс, который установит ключ, дополнительно отправит publi sh на тот же жестко закодированный канал, чтобы все, ожидающие токен, сразу получили его.
Насколько я могу видеть это должно работать просто отлично с меньшими накладными расходами, чем спин-блокировка, но, возможно, есть некоторые вещи, которые я не учел, которые делают этот подход плохой идеей?