Какой опыт работы с Zookeeper, Redis, Curator для распределённых блокировок

Что проверяют

Понимаете ли вы, что распределённая блокировка не даёт абсолютной гарантии, и знаете ли, чем подходы на ZooKeeper и на Redis отличаются по надёжности. Следом обычно спрашивают: что будет, если владелец блокировки завис на сборке мусора, а срок блокировки тем временем истёк.

Как отвечать

Расскажите, какую задачу решала блокировка (один обработчик на весь кластер, запуск задачи по расписанию только на одном узле) и почему выбрали конкретный инструмент. Технический каркас:

• ZooKeeper: клиент создаёт эфемерный последовательный узел под общим путём. Блокировку держит узел с наименьшим номером, остальные ставят watch на предыдущий, а не на весь каталог, иначе при освобождении просыпаются все сразу. Сессия умерла, эфемерный узел удалился, блокировка освободилась сама;
• Curator: эту механику прячут InterProcessMutex (реентерабельный) и InterProcessSemaphoreMutex (нереентерабельный). Захват через acquire(timeout, unit), освобождение строго в finally;
• Redis: SET key token NX PX 30000 одной атомарной командой. Связка SETNX и отдельного EXPIRE устарела: если процесс упадёт между ними, ключ останется навсегда. Снимать блокировку нужно Lua-скриптом, который сверяет токен;
• Redisson: RLock с watchdog, который продлевает срок, пока владелец жив.

Главная мысль, которую ждут: блокировка с TTL не защищает от процесса, который «проснулся» после паузы и продолжил писать. Надёжное решение это fencing token: монотонно растущий номер, который проверяет само хранилище при записи и отвергает устаревший.

Опыт подавайте своими словами и цифрами. Если работали только с одним инструментом, скажите это и объясните устройство остальных.

Где спотыкаются

Считают Redlock на нескольких независимых Redis полной гарантией. Вокруг него давно идёт спор, и без fencing token он уязвим к паузам процесса и сдвигу часов.

Освобождают блокировку обычным DEL, не проверив владельца. После истечения TTL так удаляется блокировка, которую уже взял другой процесс.

Не думают о таймауте сессии ZooKeeper: слишком короткий даёт ложные потери блокировки при сетевых задержках, слишком длинный надолго оставляет блокировку за упавшим узлом.