Bagaimana sistem pemesanan kursi bioskop mencegah beberapa pengguna memesan kursi yang sama?


34

Di bioskop saya pergi ke mereka memiliki kios tiket yang memungkinkan Anda untuk memilih kursi yang Anda inginkan; mereka juga memiliki situs web yang melakukan hal yang sama (situs web juga memiliki penghitung waktu mundur seperti 30 detik di mana Anda harus memilih tempat duduk).

Sementara saya memahami hal-hal seperti transaksi basis data dan teknik lain untuk menangani beberapa pengguna secara bersamaan, saya tidak bisa memahami bagaimana banyak orang dapat memilih kursi pada saat yang sama; Apakah sesederhana orang pertama yang menekan BELI mendapatkan kursi dan orang lain akan mendapatkan pesan kesalahan, atau apakah saya melewatkan sesuatu?


10
"Apakah sesederhana orang pertama yang menekan BELI mendapat kursi dan orang lain akan mendapatkan pesan kesalahan". Bahwa.
yannis

2
Ya mungkin, pada hari yang sibuk dengan selusin mesin sepertinya itu akan menyusahkan.
mbwasi

2
Mungkin, tetapi perlu diingat bahwa pengguna akan menghabiskan sebagian besar waktu mereka di layar lain (memasukkan rincian pembayaran, menunggu tiket untuk dicetak, dll.), Sehingga mereka tidak akan mengambil kursi pada saat yang sama, dan tidak setiap orang memiliki preferensi kursi yang sama, sehingga bahkan mereka yang memilih pada saat yang sama kemungkinan akan memilih kursi yang berbeda. Saya tidak berharap akan ada banyak tabrakan.
Dave Sherohman

2
@ Jim. Untuk setiap solusi yang mungkin, jika kedua pelanggan menekan beli pada waktu yang sama persis (ke milidetik) yang satu akan dilayani dan yang lain akan mendapatkan semacam pesan kesalahan. Ada cara-cara indah untuk meminimalkan peluang terjadinya hal itu (teknis dan konseptual, seperti yang dijelaskan dalam jawaban) tetapi dalam situasi luar biasa itu terjadi maka satu permintaan akan dilayani dan yang lainnya akan gagal. Sesimpel itu.
yannis

3
@ Jim. Itu bukan tipe perilaku. Concurrency bekerja pada satu titik, jika kedua permintaan mencapai pada microtime yang sama persis, satu akan gagal. Anda tentu saja dapat membangun pesan kesalahan yang bagus di sekitar itu, seperti dalam komentar Hand-E-Food, tetapi faktanya tetap: Ini sesederhana melayani satu permintaan dan gagal yang lain. Saya tidak mengatakan Anda tidak harus melakukan segalanya untuk memastikan bahwa kegagalan adalah sebagai ramah pengguna seperti yang seharusnya atau bahwa Anda tidak harus menjaga di sekitarnya.
yannis

Jawaban:


27

Metode klasik untuk melakukan ini adalah dengan menggunakan basis data transaksional (jadi tidak ada bentrokan) dan untuk melakukan alokasi tentatif kursi untuk Anda yang berakhir setelah beberapa lama (misalnya, 10 menit untuk kios) yang memberi Anda cukup waktu untuk membayar. Jika transaksi (yang terlihat oleh pelanggan) jatuh atau habis, alokasi kursi dapat dilepaskan kembali ke kumpulan. (Semua perubahan status diproses melalui basis data transaksional, dan satu transaksi yang terlihat oleh pelanggan mungkin memerlukan banyak transaksi tingkat basis data.)

Maskapai akan menggunakan sistem serupa (meskipun jauh lebih kompleks karena kebutuhan untuk menangani beberapa kaki penerbangan!) Untuk memesan kursi secara online. Saya akan membayangkan bahwa batas waktu akan jauh lebih lama; tiket pesawat biasanya dipesan lebih jauh dari tiket film, dan lebih mahal juga.


Ingat, bioskop lokal saya sebenarnya tidak mengalokasikan kursi secara normal. Sebagai gantinya, mereka menyediakan terlalu banyak kursi sehingga orang bisa muncul dengan sedikit keributan. Ini teknik yang berbeda, tetapi tidak satu pun yang relevan dengan pertanyaan Anda!
Donal Fellows

Mirip dengan memilih kursi untuk acara olahraga. Anda mendapatkan N jumlah kursi yang dipesan selama 3 menit sementara Anda memutuskan apakah Anda benar-benar menginginkannya dan menyelesaikan pembayaran.
AndyMcKenna

Perhatikan bahwa ada dua proses berbeda dengan, misalnya, membeli kursi maskapai: pertama, Anda membeli tiket tanpa kursi yang dialokasikan. Kedua, ketika Anda mendapatkan boarding pass Anda (atau jika Anda check-in online) maka Anda mendapatkan tempat duduk. Jumlah tiket sebenarnya oversold karena mereka tahu bahwa, rata-rata, jumlah tertentu tidak muncul untuk penerbangan. Alokasi kursi, bagaimanapun, tampaknya bekerja dengan secara acak memberikan Anda kursi (first-come-first-serve) ketika Anda check-in, dan kemudian memungkinkan Anda untuk mengubah kursi dengan memilih yang tersedia, kemudian melakukan transfer dalam satu transaksi .
Scott Whitlock

2
@ DonalFellows, bisakah Anda menjelaskan bagian alokasi tentatif lebih banyak? Apakah maksud Anda memesan beberapa kursi untuk pengguna selama jangka waktu tertentu? Saya masih mencoba memahami tantangan yang dihadapi dalam sistem jenis ini.
Sandeepan Nath

1
@SandeepanNath Tidak benar dalam komentar, tetapi prinsipnya sepele. Kursi dimasukkan ke dalam status "dialokasikan sementara", dan batas waktu dari status itu dicatat pada saat yang sama. Jika pemesanan selesai, kursi menjadi sepenuhnya dialokasikan. Jika tidak dan batas waktu tercapai, kursi (akhirnya) dipindahkan kembali ke kolam utama. (Juga, jika pengguna secara eksplisit membatalkan maka kursi dipindahkan langsung kembali ke kolam. Tidak perlu menunggu.)
Donal Fellows

4

30 detik yang Anda lihat saat ini sering kali lebih seperti 15 menit. Saya tidak percaya ada transaksi basis data aktif untuk durasi itu.

Jika saya merancang sistem seperti itu, ini adalah bagaimana saya akan melakukannya: Memiliki objek bisnis Bookingdan Reservation. Pemesanan pada dasarnya adalah pemesanan dikonfirmasi (yaitu dibayar). Saya akan menyimpannya dalam tabel DB yang sama dan membedakan dengan satu atau dua atribut.

Saat mengambil kursi yang tersedia, Anda akan meminta pemesanan dan reservasi.

Ketika seseorang memilih tempat duduk, Anda membuat reservasi baru, dengan demikian menunjukkan tempat duduk kepada pelanggan lain. Pemesanan kedua untuk kursi yang sama akan ditolak - pembaruan atau penyisipan DB akan gagal. Jika pelanggan mengonfirmasi / membayar reservasi, Anda mengalihkannya ke pemesanan. Dalam pekerjaan batch berkala, Anda menghapus semua reservasi yang lebih dari 15 menit (atau berapa pun waktu yang Anda berikan kepada pelanggan Anda).



1

Setidaknya ada 2 proses bisnis yang terlibat di sini.

  • Proses satu:

Tampilkan kursi yang tersedia.

  • Proses dua:

Pesan kursi yang dipilih.

Karena proses-proses ini tidak mengikuti satu sama lain secara tidak teratur, dan karena 2 orang dapat memilih kursi yang sama, masalah konkurensi muncul.

Jika desain database Anda memberikan batasan keunikan yang benar sehingga kombinasi dari:

-TheaterID

-SeatID

-EventID

unik, maka database akan mencegah duplikat.

Skenario berikut juga dimungkinkan tetapi akan diatasi dengan implementasi yang disarankan di atas:

Dengan asumsi tampilan grid tersedia untuk teater tertentu dan acara tertentu dapat ditampilkan:

  1. User1 menampilkan kursi yang tersedia (dan mendapat kursi 1 dan 2)
  2. User2 menampilkan kursi yang tersedia (dan mendapat kursi 1 dan 2)
  3. User1 berbicara sedikit dengan pelanggan di telepon
  4. User2 pergi dan memesan kursi 2 untuk pelanggannya
  5. User1 mencoba memesan kursi 2 untuk pelanggannya (karena terlihat tersedia di layarnya)
  6. Indeks unik mencegah langkah 5 dari pengangkutan data.

Jadi semua yang perlu Anda lakukan mungkin tidak lebih dari desain database yang benar dan pilihan yang tepat pada kendala.

Pendekatan lain yang lebih kompleks mungkin dilakukan jika Anda mau, menggunakan antrian transaksi. Dalam hal ini, permintaan dituliskan terlebih dahulu ke antrian kemudian menjalankan proses setiap n detik tetapi itu hampir tidak perlu atau praktis dalam kasus Anda.

Bagian yang sangat menarik adalah apa yang harus ditampilkan oleh grid daftar untuk pengguna 1?


1

Anda dapat menghindari kondisi balapan jika Anda menunda mengalokasikan kursi tertentu.

  1. Kumpulkan preferensi tempat duduk dari pelanggan (jumlah kursi, harga, area teater, kursi yang berdekatan wajib, dll ...)
  2. Simpan preferensi tempat duduk yang diminta dalam antrian
  3. Permintaan tempat duduk satu demi satu ditarik dari antrian, kursi yang dialokasikan sesuai dengan preferensi dan pemesanan diselesaikan jika kursi ditemukan.
  4. Jika pemesanan selesai, beri tahu pelanggan dan kirimkan tiket; jika tidak, beri tahu pelanggan bahwa tidak ada tiket yang cocok dengan preferensi.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.