Как спроектировать распределённый замок (Distributed Lock / Redlock) с помощью Redis и учесть случай, когда воркер завис в паузе GC?

TTL-lock может истечь во время паузы GC, после чего старый worker продолжит работу одновременно с новым. Для защиты ресурса нужен fencing token или проверка версии, а не только продление TTL.

Один Redis-lock захватывают атомарно через SET ... NX PX с уникальным токеном владельца; удаляют только при совпадении токена. Redlock использует несколько независимых узлов и ограниченное окно владения, но не останавливает зависший процесс физически. После паузы старый worker может считать себя владельцем ошибочно. Хранилище результата должно отклонять устаревший монотонный fencing token, выдаваемый надёжным координатором. Случайный токен Redis нужен для владения, но не заменяет fencing. Для строгих инвариантов рассматривают транзакции БД или consensus-based координацию.

Источник: redis.io.