Синхронизация заявки на бронирование C#/asp.net

Question

Я разрабатываю приложение для бронирования событий, и мне трудно понять, как управлять процессом бронирования. Я знаю о транзакциях db и немного о блокировке, но у меня есть много бизнес-правил для проверки, прежде чем можно будет совершить бронирование, и я беспокоюсь о узких местах работы.

Вот краткое описание того, что происходит:

• Событие имеет максимальное количество слотов
• Пользователь может заказать одно место в турнире
• Каждый пользователь имеет счет денег и каждое событие стоит определенное количество

Учитывая вышеуказанные параметры, следующие бизнес-правила, что мне нужно проверить для бронирования иметь место:

• Пользователь еще не забронировали место для этого события
• Пользователь имеет достаточно средств, чтобы заказать это событие
• Событие имеет по крайней мере одно место доступно
• Событие не конфликтует с другими события, которые пользователь забронировал (не столько проблема, сколько я могу проверить это при отображении страницы и скрыть это событие от пользователя)

Мое главное беспокойство заключается в том, что если я вытащу всю информацию из базы данных фронт (т.е. Событие, пользователь, учетная запись и существующие заказы), который к тому времени, когда я запустил всю проверку и приступаю к совершению нового бронирования, состояние системы, возможно, изменится (т.е. кто-то забронировал последнее место, деньги оставили мой счет и т. д.).

Если бы я блокировал таблицы кода/базы данных вокруг этого процесса бронирования, я потенциально (??) получил блокировку на некоторое время, влияя на другие операции в системе и вызывая проблемы с производительностью в часы пиковой нагрузки.

Может ли кто-нибудь предложить подход, посредством которого я могу управлять или, по крайней мере, ограничивать эти проблемы.

Я строю приложение asp.net в C# и с помощью SQL Server 2005.

Answer 1

Я думаю, хороший пример, чтобы посмотреть на то, как Ticketmaster оставляет места для билетов, которые могут получить закупленных. Они говорят вам, что у вас так много минут, пока сиденья не будут возвращены в инвентарь. Это подталкивает покупателя к принятию решения, или у кого-то еще будет шанс на места. Это действительно ваше самое большое препятствие. Что касается проверки бизнес-правил, вам придется это сделать. Магии нет, что нужно делать там. Если вам нужны данные для проверки правильности, то это то, что вам нужно сделать. При некотором правильном отображении и изложении вы можете найти эффективность. Надеюсь, это ответит на ваш вопрос.

Удачи вам!

Answer 2

Одно из решений:

1. упреждающие забронировать место (со статусом "держать").
2. Подтвердить.
3. Если бронирование не может быть выполнено в связи с правилами ведения бизнеса, удалите его.Если нет, измените статус на «забронированный»

Answer 3

Если вы вернетесь в 80-е годы и прочитаете литературу, опубликованную на тему обработки транзакций, вы обнаружите, что одним из наиболее обсуждаемых примеров были системы бронирования авиакомпаний. И по уважительной причине, поскольку это была одна из тем OLTP, которая выявила все проблемы, связанные с обработкой транзакций: правильность, сквозняк, конфликт, взаимоблокировки. То, что вы описываете, - очень схожая проблема, но вместо посадочных мест на воздушном транспорте у вас есть игровые автоматы. Так что да, у вас будут все эти проблемы.

Не существует волшебной пыли эльфа. Это сложная проблема. Но есть некоторые направляющие линии:

• Забытый Фред не может заблокировать слот навсегда. Забывающий Фред - это пользователь, который открывает экран бронирования, выбирает место, затем идет на обед, не закончив сделку. Если это разрешено, тогда система будет медленно «просачивать» слоты, которые не используются.
• Блокировки базы данных слишком дороги, чтобы их можно было удерживать во время ожидания ввода пользователя.
• Пропускная способность может быть достигнута только с помощью гранулированных замков.
• Бизнес-логика не должна пытаться согласовывать обновления на коррелированных элементах.
• Все отображаемое пользователю должно рассматриваться как «предварительное».
• Пользовательский интерфейс должен быть подготовлен для обработки конфликтов обновления.
• Логика обновления должна всегда следовать одной и той же иерархии (например, если согласованная логика обновления - Account-> User-> Event-> Booking, то транзакция с изгоем, пытающаяся обновить Booking-> Event-> User, приведет к взаимоблокировкам).

И в самом деле существует подход, который ограничивает эти проблемы: workflow processing при поддержке transactional queues, которые используют correlated items exclusive lock out. Не ваша повседневная задача ASP наверняка, поэтому я рекомендую вам придерживаться того, что вы знаете.