Комментарии 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, например), но всё это... неудобно.

Распределенная блокировка RedLock.NET. Просто и со вкусом