Распределенные блокировки в микросервисной архитектуре

Question

У нас есть настройка архитектуры, при которой клиентское приложение выполняется на сервере, и мы хотели бы иметь микросервис, отвечающий за предоставление функций распределенной блокировки / карты / кэша. Этот сервис Micro внутри компании использует Redisson, клиент java, который может общаться с Redis. Теперь мы хотели бы предоставить apis lock, unlock, get, put из сервиса Micro, который может использовать клиентское приложение. Для связи между приложениями и микро сервисами мы будем использовать протокол gRP C.

Как правильно предложить клиенту блокировку / разблокировку apis от Microservice? В настоящее время мы используем Semapbase от Redisson на RedissonMap RMap.getLock (..)), и оно следует java Спецификация блокировки, поэтому поток, который получает только распределенную блокировку, может разблокировать. Одна из проблем заключается в том, что поскольку блокировка обрабатывается микросервисом, клиент должен делать отдельные запросы на блокировку и разблокировку, которые могут обслуживаться или не обслуживаться одним и тем же узлом (микросервисом) и одним и тем же потоком. это можно обойти, используя семафор (с 1 разрешением). Таким образом, по существу мы используем Rsemaphore of redisson для сервера сценария взаимного исключения

. Мне более интересно узнать, какими должны быть факторы, которые необходимо учитывать при разработке API spe c для приобретения. / release, например, должен ли запрос на получение / разблокирование разрешений в Microservice быть синхронным или асинхронным.

Answer 1

У меня похожая проблема - В какой-то момент - если это не «опрос», только микросервису придется блокировать клиента, чтобы дождаться завершения семафора. Если блокировка неприемлема, тогда нет необходимости в семафоре. Следующий лог c должен работать нормально, даже если каждый вызов происходит из другой JVM (возможно, с первоначальным подключением к redis из этой JVM). Используйте один из объектов RLock или Atomi c только временно - достаточно долго обновить ключ или запись карты с некоторым уникальным идентификатором (предоставленным клиентом или микросервисом). Затем он сохраняется «безопасно» в Redis и указывает на что-то вроде «блокировки». Если вы используете срок действия ключа, то это дает вам TTL для «блокировки».

Если ваше приложение может блокировать микросервис во время ожидания освобождения семафора, то вызовы из разных микросервисов должны работать нормально. Это та же самая модель, как если бы у вас было 2 длительно работающих JVM, напрямую подключенных к redis / redisson, но каждая использовала семафор только один раз. когда вы вернетесь к клиенту, позже вызовите микросервис (другой JVM), чтобы снять блокировку.

Answer 2

, например, должен ли запрос на получение / разрешение разрешений в Микросервисе быть синхронным или асинхронным

Это зависит от логики c, применяемой семафором. Использовать asyn c путь только для асинхронных логи c, выполняемых внутри блока получения / освобождения.