W kinie chodzę do nich, mają kioski z biletami, które pozwalają wybrać miejsca, które chcesz; Mają też stronę internetową, która robi to samo (strona internetowa ma również odliczanie czasu wynoszące około 30 sekund, w którym musisz wybrać miejsce).
Chociaż rozumiem takie rzeczy, jak transakcje w bazie danych i inne techniki obsługi wielu jednoczesnych użytkowników, po prostu nie mogę się zastanowić, jak wiele osób może wybrać miejsce jednocześnie; czy to tak proste, jak naciśnięcie pierwszego przycisku KUP dostaje miejsca, a druga osoba otrzyma komunikat o błędzie, czy coś mi brakuje?
concurrency
mbwasi
źródło
źródło
Odpowiedzi:
Klasyczną metodą jest skorzystanie z transakcyjnej bazy danych (aby uniknąć kolizji) i dokonanie wstępnej alokacji miejsca, która wygasa po pewnym czasie (np. 10 minut w przypadku kiosków), co daje wystarczająco dużo czasu na zapłacić. Jeśli transakcja (widoczna dla klienta) upadnie lub upłynie limit czasu, przydział miejsc może zostać zwolniony z powrotem do puli. (Wszystkie zmiany stanu są przetwarzane za pośrednictwem transakcyjnej bazy danych, a jedna transakcja widoczna dla klienta może wymagać wielu transakcji na poziomie bazy danych).
Linie lotnicze będą korzystać z podobnego systemu (choć o wiele bardziej złożonego ze względu na konieczność obsługi wielu etapów lotu!) Do rezerwacji miejsc online. Wyobrażam sobie, że limit czasu byłby znacznie dłuższy; bilety lotnicze są zwykle rezerwowane z wyprzedzeniem niż bilety do kina i są również droższe.
źródło
30 sekund, które widziałeś, obecnie są często bardziej jak 15 minut. Nie sądzę, aby w tym czasie była aktywna transakcja bazy danych.
Gdybym miał zaprojektować taki system, zrobiłbym to w ten sposób: mieć obiekty biznesowe
Booking
iReservation
. Rezerwacje są zasadniczo potwierdzonymi (tj. Płatnymi) rezerwacjami. Chciałbym przechowywać je w tej samej tabeli DB i rozróżniać według atrybutu lub dwóch.Podczas pobierania dostępnych miejsc można wyszukiwać zarówno rezerwacje, jak i rezerwacje.
Gdy ktoś wybierze miejsce, tworzysz nową rezerwację, pokazując tym samym innym klientom miejsce zajęte. Druga rezerwacja dla tego samego miejsca zostanie odrzucona - aktualizacja DB lub wstawienie zakończy się niepowodzeniem. Jeśli klient potwierdzi / zapłaci za rezerwację, przejdziesz na rezerwację. W okresowym zadaniu wsadowym usuwasz wszystkie rezerwacje starsze niż 15 minut (lub o dowolnej godzinie, którą podajesz swoim klientom).
źródło
Jest zgodny z właściwością ACID bazy danych - Izolacja. Baza danych używa blokad danych, aby uniknąć jednoczesnej modyfikacji danych.
http://en.wikipedia.org/wiki/Isolation_%28database_systems%29
źródło
W grę wchodzą co najmniej 2 procesy biznesowe.
Pokaż dostępne miejsca.
Zarezerwuj wybrane miejsce.
Ponieważ procesy te nie następują po sobie nadmiernie, a ponieważ 2 osoby mogą wybrać to samo miejsce, pojawia się problem współbieżności.
Jeśli projekt bazy danych przypisuje poprawne ograniczenie unikatowości, aby kombinacja:
-TheaterID
-SeatID
-EventID
są unikalne, baza danych zapobiegnie duplikowaniu.
Możliwy jest również następujący scenariusz, który zostanie rozwiązany przez powyższą sugerowaną implementację:
Zakładając widok siatki dostępnej dla danego teatru i danego zdarzenia można wyświetlić:
Tak więc wszystko, co musisz zrobić, to nic więcej jak poprawny projekt bazy danych i właściwy wybór ograniczeń.
W razie potrzeby możliwe są inne, bardziej złożone podejścia, przy użyciu kolejek transakcji. W takim przypadku żądania są zapisywane najpierw w kolejce, a następnie uruchamiane co n sekund, ale nie jest to konieczne ani praktyczne w twoim przypadku.
Naprawdę interesującą częścią jest to, co powinna pokazywać siatka listy dla użytkownika 1?
źródło
Możesz uniknąć warunków wyścigu, jeśli opóźnisz przydzielenie określonych miejsc.
źródło