Comments 16
-- Если строка возвращена, обновляем её
# S2
UPDATE seats
SET status = 'RESERVED', user_id = 'U456', reserved_at = NOW()
WHERE seat_id = 'A1' AND event_id = 'E123';Ну кто так делает? Руки оторвать... Где условие
AND status = 'AVAILABLE'???
Тоже это было первое, что подумал. Проблема как бы высосана из пальца без этого условия.
Ну да. Более того, это дополнение делает абсолютно бессмысленным первый запрос - на существование "свободной" записи. Но требует дополнительного запроса после - проверяющего, что резервирование состоялось, и что отбор по всем параметрам возвращает зарезервированную запись. Ибо ориентироваться на отсутствие ошибки и количество изменённых записей - это тоже детский сад. Хотя такой запрос должен состояться в любом случае, хоть с исправлением, хоть без..
Забавно, что впервые встретил очередь на бронирование пару недель назад в Диснейленде - для бронирования ресторанов. До этого только читал, что на олимпиадах такое практикуют.
Мне кажется, хранить блокировки лучше подальше от базы, поближе к бизнес-логике. А в базу отправлять готовые транзакции.
Отличная статья, отличный перевод. Спасибо большое!
Стоит отметить несколько нюансов:
Не все решения подойдут, если состояние хранится в No-SQL базе данных, не поддерживающей ACID.
Всё становится веселей, если состояние в системе географически распределено, и работает в режиме "eventual consistency". Тогда все ваши метки и флаги (внутри модели данных) будут иметь силу только в случае когда запросы обрабатываются на одном экземпляре базы данных.
Иногда получается так, что решить эту проблему за адекватное время и ресурсы просто не получается. Тогда решением может быть - "просто забить" и обрабатывать результаты "овербукинга" на бизнес-уровне. Так отели делают достаточно часто. Им дешевле сделать вам апгрейд номера (который и так стоит пустой), чем отказать вам в брони.
Пункт 3 - неверно. В случае оптимистичной блокировки - ресурсы нужны минимальные как раз. И овербукинга не будет. "овербукинг" в отелях - это бизнес решение, а не техническое. Когда владельцы СПЕЦИАЛЬНО разрешают овербукинг для увеличения прибыли, т.к. рассчитывают на то что часть букингов не будет реализована
Табличка а конце нарисована странно - почему в нижней строке есть как 4 зеленых кружочка, так и 4 красных? В остальных строках есть логика - чем больше, тем зеленее. А тут?
Про очередь я кстати не понял как оно работает. Вот я покупаю билет на концерт, с выбором места. Зашел на страницу, и сижу жду очереди. Окей, подошла моя очередь, я вижу зал с свободными местами и начинаю думать какое мне выбрать. И тут вопрос - вся остальная очередь в этот момент ждет меня, пока я не выберу и не оплачу?? А сколько у меня времени, хотябы минут 10 есть ??? Или остальная очередь не ждет? Так тогда опять такая же гонка получается, с оптимистичной блокировкой, только перед ней еще надо очередь отстоять. Ничего не понятно
Тоже до конца не понял, но подозреваю, что в очередь для начала ставятся попытки зарезервировать места для покупки (чтобы ограничить конкуренцию на этом этапе), а уже затем, если резервирование прошло успешно, оно живет ограниченное время в ожидании оплаты.
а если кто-то впереди тебя в очереди пытается забронировать тоже самое место. То что? когда подходит твоя очередь - ты получаешь отказ, и откатываешься в самое начало? Снова стоять всю очередь в попытке забукать другое место??
По итогам короткой сессии с ChatGPT выяснилось, что в очередь попадают запросы на получение доступа к сессии бронирования. То есть пользователь заходит на сайт, видит места, но выбрать пока ничего не может. Когда очередь до него доходит, активируется сессия бронирования с ограничением по времени. Активных сессий одновременно много, то есть мы просто ограничиваем количество потенциально конкурентных запросов. Дальше используются те же механизмы (оптимистичная блокировка или блокировки в redis) для разруливания конкурентных запросов от пользователей, чьи сессии сейчас активны.
иишная статья для уж очень простого кейса.
А теперь попробуйте запилить систему систему букинга комнаты например где есть roomId + checkIn + checkOut, и что б в перформанс, и что б в каких-то случаях разрешался овербукинг а в каких-то нет. И что б как минимум можно было забукать в период 2 года вперед.
Например, как будете делать что бы букинг первой недели года и последней недели через 2 года разными людьми одной комнаты - не конфликтовали? ;) Или все же для бизнеса лучше не надо даже пытаться... и все таки дешевле обнаруживать овербукинг позже и отменять чем пытаться предотвратить при помощи блокировок?
Решение проблемы двойного букинга: паттерны проектирования систем