मूवी थिएटर सीट बुकिंग सिस्टम एक से अधिक उपयोगकर्ताओं को एक ही सीट रखने से कैसे रोकता है?


34

फिल्म थिएटर में मैं उनके पास टिकट कियोस्क जाता हूं जो आपको अपनी इच्छित सीटों का चयन करने की अनुमति देता है; उनके पास एक वेबसाइट भी है जो ऐसा ही करती है (वेबसाइट में 30 सेकंड की एक उलटी गिनती का टाइमर भी है जिसमें आपको एक सीट का चयन करना होगा)।

जब मैं एक साथ कई उपयोगकर्ताओं को संभालने के लिए डेटाबेस लेन-देन और अन्य तकनीकों जैसी चीजों को समझता हूं, तो मैं बस अपना सिर इधर-उधर नहीं कर सकता कि कितने लोगों को एक ही समय में एक सीट का चयन करने की अनुमति दी जा सकती है; क्या यह उतना ही सरल है जितना कि पहले प्रेस करने पर बुवाई को सीटें मिलती हैं और दूसरे व्यक्ति को एक त्रुटि संदेश मिलेगा, या क्या मुझे कुछ याद आ रहा है?


10
"क्या यह उतना ही सरल है जितना कि प्रेस करने वाले पहले व्यक्ति को सीटें मिलेंगी और दूसरे व्यक्ति को एक त्रुटि संदेश मिलेगा"। उस।
यानिस

2
हाँ शायद, एक दर्जन मशीनों की तरह एक उबाऊ दिन पर ऐसा लगता है कि हालांकि एक दर्द होगा।
mbwasi

2
शायद, लेकिन ध्यान रखें कि उपयोगकर्ता अपना अधिकांश समय अन्य स्क्रीन (भुगतान विवरण दर्ज करना, टिकट प्रिंट करने के लिए इंतजार करना, इत्यादि) पर खर्च करेंगे, इसलिए वे सभी एक ही समय में सीटें नहीं लेंगे, और नहीं सभी के पास एक ही सीट प्राथमिकता है, इसलिए भी जो एक ही समय में उठा रहे हैं, वे अलग-अलग सीटों को चुनने की संभावना रखेंगे। मुझे उम्मीद नहीं है कि सभी कई टकराव होंगे।
डेव शेरोमैन

2
@JimG। हर संभव समाधान के लिए, यदि दोनों ग्राहक सटीक एक ही समय (मिलीसेकंड पर) खरीदते हैं तो एक को सेवा मिलेगी और दूसरे को किसी प्रकार का त्रुटि संदेश मिलेगा। उस होने की संभावना को कम करने के सुंदर तरीके हैं (तकनीकी और वैचारिक, जैसा कि उत्तरों में समझाया गया है) लेकिन असाधारण स्थिति में ऐसा होता है तो एक अनुरोध परोस दिया जाएगा और दूसरा विफल हो जाएगा। कि जैसे ही आसान।
यानि

3
@JimG। यह एक प्रकार का व्यवहार नहीं है। कंसीडर एक बिंदु पर काम करता है, अगर दोनों अनुरोध एक ही माइक्रोटाइम पर पहुंचते हैं, तो एक विफल हो जाएगा। आप निश्चित रूप से हैंड-ई-फूड की टिप्पणी के अनुसार, एक अच्छा त्रुटि संदेश बना सकते हैं, लेकिन तथ्य यह है: यह एक अनुरोध की सेवा करने और दूसरे को विफल करने जैसा ही सरल है। मैं यह नहीं कह रहा हूं कि आपको यह सुनिश्चित करने के लिए सब कुछ नहीं करना चाहिए कि विफल होना उपयोगकर्ता के अनुकूल है क्योंकि यह हो सकता है या आपको इसके चारों ओर सुरक्षा नहीं करनी चाहिए।
यानिस

जवाबों:


27

ऐसा करने के लिए क्लासिक विधि एक ट्रांसेक्शनल डेटाबेस का उपयोग करना है (ताकि कोई झड़प न हो) और आपको सीट का एक अस्थायी आवंटन करना है जो कुछ समय के बाद समाप्त हो जाता है (जैसे, कियोस्क के लिए 10 मिनट) जो आपको पर्याप्त समय देता है वेतन। यदि ग्राहक (ग्राहक-दृश्य) लेनदेन के माध्यम से या कई बार बाहर हो जाता है, तो सीट आवंटन वापस पूल में जारी किया जा सकता है। (सभी राज्य परिवर्तनों को लेन-देन डेटाबेस के माध्यम से संसाधित किया जाता है, और एक ग्राहक-दृश्य लेनदेन के लिए कई डेटाबेस-स्तरीय लेनदेन की आवश्यकता हो सकती है।)

एयरलाइंस ऑनलाइन बुकिंग के लिए एक समान प्रणाली (हालांकि कई फ्लाइट लेग को संभालने की आवश्यकता के कारण अधिक जटिल है) का उपयोग करेगी। मुझे लगता है कि समय समाप्त हो जाएगा काफी लंबा; एयरलाइन टिकट आमतौर पर मूवी टिकट की तुलना में आगे बुक किए जाते हैं, और साथ ही अधिक महंगे होते हैं।


ध्यान रहे, मेरा स्थानीय फिल्म थियेटर वास्तव में सामान्य रूप से सीटें आवंटित नहीं करता है। इसके बजाय, उन्होंने सीटों पर अधिक प्रावधान किया ताकि लोग कम से कम उपद्रव कर सकें। यह एक अलग तकनीक है, लेकिन आपके प्रश्न के लिए प्रासंगिक नहीं है!
डोनल फैलो

खेल स्पर्धाओं के लिए सीटें भरने के समान। आपको अपनी एन सीटों की संख्या 3 मिनट के लिए आरक्षित है जबकि आप तय करते हैं कि क्या आप वास्तव में उन्हें चाहते हैं और भुगतान पूरा करते हैं।
एंडीमकेनना

उदाहरण के लिए, एयरलाइन की सीटें खरीदने के साथ, दो अलग-अलग प्रक्रियाएं हैं: सबसे पहले, आप बिना आवंटित सीट के टिकट खरीदते हैं। दूसरा, जब आप अपना बोर्डिंग पास प्राप्त करते हैं (या यदि आप ऑनलाइन जांच करते हैं) तो आपको सीट मिल जाती है। टिकटों की संख्या वास्तव में ओवरसोल्ड है क्योंकि वे जानते हैं कि, औसतन, एक निश्चित संख्या उड़ान के लिए दिखाई नहीं देती है। सीट आवंटन, हालांकि, बेतरतीब ढंग से आपको एक सीट (पहले आओ-पहले पाओ) बताकर काम करने लगता है, जब आप चेक-इन करते हैं, और फिर आपको एक उपलब्ध उठाकर सीट बदलने की अनुमति देता है, फिर एक ही लेनदेन में स्थानांतरण करना ।
स्कॉट व्हिटलॉक 12

2
@DonalFellows क्या आप अस्थायी आवंटन हिस्से को थोड़ा और समझा सकते हैं? क्या आपका मतलब कुछ समय के लिए उपयोगकर्ता के लिए कुछ सीटें आरक्षित करना है? मैं अभी भी इस प्रकार की प्रणाली में आने वाली चुनौतियों का सामना करने की कोशिश कर रहा हूं।
संदीपन नाथ

1
@ संदीपननाथ एक टिप्पणी में ठीक से नहीं, लेकिन सिद्धांत तुच्छ है। सीट को "अस्थायी रूप से आवंटित" स्थिति में रखा गया है, और उस समय का समय एक ही समय में नोट किया गया है। यदि बुकिंग पूरी हो जाती है, तो सीट पूरी तरह से आवंटित हो जाती है। यदि नहीं और समय समाप्त हो गया है, तो सीट (अंततः) मुख्य पूल में वापस चली गई है। (इसके अलावा, यदि उपयोगकर्ता स्पष्ट रूप से रद्द करता है, तो सीट सीधे पूल में वापस ले जाया जाता है। प्रतीक्षा करने की आवश्यकता नहीं है।)
डोनल फैलो

4

आपने जो 30 सेकंड देखे हैं वे आजकल 15 मिनट से अधिक हैं। मेरा मानना ​​है कि उस अवधि के लिए एक डेटाबेस लेनदेन सक्रिय है।

अगर मुझे ऐसी प्रणाली डिजाइन करनी थी, तो यह है कि मैं यह कैसे करूंगा: व्यावसायिक वस्तुएं हों Bookingऔर Reservation। बुकिंग अनिवार्य रूप से (यानी भुगतान) आरक्षण की पुष्टि कर रहे हैं। मैं उन्हें एक ही DB तालिका में संग्रहीत करता हूं और एक विशेषता या दो से अलग करता हूं।

उपलब्ध सीटों को लाने के दौरान, आप बुकिंग और आरक्षण दोनों की क्वेरी करेंगे।

जब कोई सीट का चयन करता है, तो आप एक नया आरक्षण बनाते हैं, इस प्रकार अन्य ग्राहकों को सीट लेते हुए दिखाया जाता है। उसी सीट के लिए एक दूसरे आरक्षण को अस्वीकार कर दिया जाएगा - डीबी अपडेट या सम्मिलित विफल हो जाएगा। यदि ग्राहक आरक्षण के लिए पुष्टि करता है / भुगतान करता है, तो आप इसे बुकिंग में बदल देते हैं। एक आवधिक बैच की नौकरी में आप 15 मिनट (या जो भी आप अपने ग्राहकों को देते हैं) से पुराने सभी आरक्षण हटाते हैं।



1

यहां कम से कम 2 व्यावसायिक प्रक्रियाएं शामिल हैं।

  • प्रक्रिया एक:

उपलब्ध सीटें दिखाएं।

  • प्रक्रिया दो:

एक चयनित सीट बुक करें।

चूँकि ये प्रक्रियाएँ एक दूसरे को अनैतिक रूप से पालन नहीं करती हैं, और चूंकि 2 लोग उसी सीट का चयन कर सकते हैं जो समवर्ती समस्या उत्पन्न होती है।

यदि आपके डेटाबेस का डिज़ाइन सही विशिष्टता अवरोध प्रदान करता है, ताकि निम्नलिखित का संयोजन हो:

-TheaterID

-SeatID

-EventID

अद्वितीय हैं, फिर डेटाबेस डुप्लिकेट को रोक देगा।

निम्नांकित परिदृश्य भी संभव है लेकिन उपर्युक्त क्रियान्वयन द्वारा ध्यान रखा जाएगा:

किसी दिए गए थिएटर के लिए उपलब्ध ग्रिड दृश्य और दिए गए कार्यक्रम को प्रदर्शित किया जा सकता है:

  1. उपयोगकर्ता 1 उपलब्ध सीटों को प्रदर्शित करता है (और सीटें 1 और 2 प्राप्त करता है)
  2. उपयोगकर्ता 2 उपलब्ध सीटों को प्रदर्शित करता है (और सीटें 1 और 2 प्राप्त करता है)
  3. User1 फोन पर ग्राहक के साथ थोड़ी बातचीत करता है
  4. User2 जाता है और किताबें अपने ग्राहक के लिए सीट 2
  5. User1 अपने ग्राहक के लिए सीट 2 बुक करने की कोशिश करता है (क्योंकि यह उसकी स्क्रीन पर उपलब्ध है)
  6. यूनिक इंडेक्स स्टेप 5 को डेटा को कम्यूट करने से रोकता है।

तो आपको जो कुछ करने की ज़रूरत है वह कुछ और सही डेटाबेस डिज़ाइन और बाधाओं पर उचित विकल्प नहीं हो सकता है।

लेन-देन कतारों का उपयोग करते हुए यदि आप चाहते हैं, तो अन्य अधिक जटिल दृष्टिकोण संभव हैं। इस मामले में, अनुरोध पहले एक कतार में लिखे जाते हैं, फिर हर n सेकंड में एक प्रक्रिया निकालते हैं लेकिन यह आपके मामले में शायद ही आवश्यक या व्यावहारिक है।

वास्तव में दिलचस्प हिस्सा यह है कि उपयोगकर्ता 1 शो के लिए सूची ग्रिड क्या होना चाहिए?


1

यदि आप विशिष्ट सीटें आवंटित करने में देरी करते हैं तो आप दौड़ की स्थिति से बच सकते हैं।

  1. ग्राहक से बैठने की प्राथमिकताएँ (सीटों की संख्या, मूल्य, रंगमंच का क्षेत्र, आसन्न सीटें अनिवार्य, आदि ...) लीजिए
  2. कतार में अनुरोधित बैठने की वरीयताओं को सहेजें
  3. एक-एक करके बैठने के अनुरोध कतार से खींचे जाते हैं, वरीयता के अनुसार आवंटित सीटें और यदि सीटें मिलीं तो बुकिंग पूरी हो गई है।
  4. यदि बुकिंग पूरी हो गई है, तो ग्राहकों और मेल टिकटों को सूचित करें; अन्यथा, ग्राहक को सूचित करें कि कोई टिकट वरीयताओं से मेल नहीं खाता है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.