Java/Backend. Интервью. Сценарный вопрос про распределенный лок:

У тебя есть критичный сервис, допустим обработка заказов, который крутится на нескольких инстансах в Kubernetes. Чтобы избежать гонки, когда два инстанса одновременно берут один и тот же заказ, ты ставишь распределенный лок через Redis setnx с TTL 10 секунд.

Какой критичный кейс все равно возможен, если один из инстансов словит Full GC паузу длиной 15 секунд сразу после получения лока? Опиши ситуацию split-brain и к чему она приведет по данным.

Как это разруливать на интервью:

→ сначала важно отметить, что простой Redis-лок с TTL помогает, если сервис просто упал, но создает новую, куда более опасную проблему

→ баг в том, что длинная пауза, например Full GC, может быть дольше, чем TTL лока

→ и вот что ломается (Split-Brain):

Service A берет лок,
и тут же уходит в GC на 15 секунд

Через 10 секунд Redis удаляет лок по TTL

Service B спокойно берет тот же лок,
и начинает обрабатывать заказ

Через 15 секунд Service A просыпается
все еще уверенный, что лок у него
и тоже обрабатывает этот же заказ

→ итог: два сервиса одновременно трогают один и тот же заказ. Данные ломаются. Например клиенту списывают деньги дважды.

→ реальное решение (меняем дизайн): вообще избавиться от лока

Кладем заказы в очередь сообщений,
например Kafka или RabbitMQ

Consumer group с несколькими инстансами читает этот топик

Брокер гарантирует, что каждое сообщение (заказ) уходит только одному инстансу из группы

👉 Java Portal