Обновить

Комментарии 3

С pg_advisory_lock для меня основное ограничение в том, что она только bigint принимает (8 байт). Произвольную строку в качестве ключа тут использовать не получится, guid использовать не получится... RedLock поэтому оказывается удобней.

все верно pg_advisory_lock только bigint примет или два int как ключ. Строковый ключ использовать не получится.

Хотя как по мне не самое критичное ограничение)

А вот Redis (и RedLock в частности ) начинает выигрывать за счет того, что уже все чаще и чаще во многих сервисах просто нет БД. Если нет и БД а есть Redis то выбор очевиден. Если нет и Redis и БД, то тоже реальней и правильней подключить корпоративный Redis для блокировки.

Хотя у коллег был забавный случай - у них Guid хэшировался и передавался в pg_advisory_lock. Зачем это было делать не ясно. Но факт имел место )

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации