Спроектируй распределённый сервис блокировок, который обеспечивает взаимное исключение между несколькими узлами в распределённой системе. Рассмотри механизмы получения и освобождения блокировок, политики timeout и expiry для предотвращения deadlock'ов от упавших процессов, гарантии справедливости на основе FIFO, реализацию fencing token'ов для предотвращения доступа устаревших владельцев блокировок к ресурсам, стратегии репликации для высокой доступности и техники оптимизации производительности при высокой конкуренции.

Обзор

Распределённый сервис блокировок гарантирует, что в один момент времени доступ к общему ресурсу может получить только один узел из множества машин. Ключевые реализации включают ZooKeeper, etcd и Redis-based Redlock.

Захват и освобождение блокировки

• Клиенты запрашивают блокировку, записывая данные в хранилище с консенсусом (например, etcd с Raft или ZooKeeper с ZAB)
• Блокировка предоставляется только когда большинство узлов подтверждает запись
• При освобождении клиент явно удаляет запись блокировки
• Если клиент аварийно завершает работу, блокировка автоматически истекает через TTL (Time-To-Live)

Таймауты и срок действия (Предотвращение дедлоков)

• Каждой блокировке выдаётся время аренды (например, 10 секунд)
• Если владелец не продлит аренду до истечения срока, блокировка автоматически освобождается
• Клиенты должны периодически отправлять heartbeat для продления аренды, пока они ещё активны

Справедливость благодаря FIFO-порядку

• ZooKeeper достигает справедливости, используя последовательные ephemeral znodes — каждый клиент создаёт узел и ждёт, пока не окажется с наименьшим порядковым номером
• Это гарантирует строгий FIFO-порядок без проблемы thundering herd

Fencing-токены

• Каждой выданной блокировке присваивается монотонно возрастающий токен (например, номер ревизии etcd)
• Защищённый ресурс отклоняет любой запрос с токеном ниже последнего увиденного значения
• Это защищает от ситуации, когда устаревший владелец блокировки портит целостность данных после истечения своей аренды

Репликация для высокой доступности

• Используй кластер на основе Raft или Paxos (etcd, Consul) для репликации состояния блокировок
• Redlock требует получения блокировок на большинстве независимых узлов Redis

Производительность при высокой конкуренции

• Используй exponential backoff с jitter для снижения волн ретраев
• Разделяй блокировки по неймспейсам ресурсов для распределения нагрузки
• Кешируй метаданные блокировок на клиенте, чтобы минимизировать сетевые обращения