API के साथ काम करते समय ऑर्डर के डुप्लिकेट: कारण और सुरक्षा
एक ही कार्रवाई के बाद डुप्लिकेट क्यों आते हैं
पैनल का मालिक एक बार बटन दबा सकता है और कई समान ऑर्डर देख सकता है: सब्सक्राइबर, व्यूज़, रिएक्शन या किसी अन्य सेवा के लिए। आम तौर पर समस्या क्लिक में नहीं, बल्कि क्लाइंट, API, डेटाबेस और सप्लायर के बीच की चेन में होती है।
सर्वर की नज़र से «एक अनुरोध» हमेशा एक नहीं होता। क्लाइंट को जवाब नहीं मिला, उसने भेजना दोहराया, और पहला ऑपरेशन पहले ही सेव हो चुका था। कभी-कभी ऑर्डर पैनल के डेटाबेस में एक बार बनता है, लेकिन सप्लायर के पास दो बार चला जाता है। ये अलग-अलग परिदृश्य हैं, और इन्हें अलग-अलग तरीक़े से ठीक किया जाता है।
टाइमआउट का मतलब यह नहीं कि ऑर्डर नहीं बना
सबसे आम कारण यह है कि क्लाइंट सीमित समय तक जवाब का इंतज़ार करता है। सर्वर अनुरोध स्वीकार करता है, ऑर्डर बनाता है, लेकिन तय टाइमआउट के बाद जवाब देता है। क्लाइंट ऑपरेशन को असफल मानता है और उसे दोबारा भेजता है।
नतीजे में पहला ऑर्डर पहले से डेटाबेस में है, और दूसरा अनुरोध एक और बना देता है। यह ख़ास तौर पर बाहरी API के धीमे जवाब, ओवरलोडेड क्यू या सेवाओं के बीच अस्थिर कनेक्शन के समय होता है।
टाइमआउट केवल जवाब न मिलने की बात कहता है, अनुरोध के प्रोसेस न होने की नहीं।
क्लाइंट की ओर से अपने-आप दोबारा भेजना
HTTP अनुरोधों के लिए लाइब्रेरी, बैकग्राउंड टास्क और इंटीग्रेशन सेवाएँ अक्सर अनुरोध अपने-आप दोहराती हैं। इसका कारण कनेक्शन एरर, सर्वर का रिस्पॉन्स कोड, नेटवर्क टूटना या बहुत देर से जवाब हो सकता है।
दोहराना अपने आप में उपयोगी है: यह अस्थायी गड़बड़ियों के समय खोए ऑर्डर की संख्या कम करता है। इस तरीक़े की कमी यह है कि दोबारा प्रोसेसिंग से सुरक्षा के बिना यह नेटवर्क की किसी भी अस्थिरता को डुप्लिकेट में बदल देता है।
- दोहराना साइट या बॉट के कोड में शुरू हो सकता है;
- क्यू टास्क को फिर से शुरू कर सकता है;
- अनुरोध प्रॉक्सी या इंटीग्रेशन मॉड्यूल दोहरा सकता है;
- ऑपरेटर एरर के बाद ऑर्डर मैन्युअली दोबारा भेज सकता है।
दोबारा अनुरोध पहले जवाब से पहले आ जाता है
कभी-कभी दो समान अनुरोध वाक़ई लगभग एक साथ API तक पहुँच जाते हैं। उदाहरण के लिए, उपयोगकर्ता ने फ़ॉर्म दो बार भेज दिया, फ़्रंटएंड ने बटन ब्लॉक नहीं किया या बैकग्राउंड टास्क पहले के पूरा होने से पहले फिर शुरू हो गया।
अगर हैंडलर पहले ऑर्डर की मौजूदगी जाँचता है और फिर उसे बनाता है, तो दो समानांतर ऑपरेशन एक साथ जाँच पास कर सकते हैं। दोनों देखेंगे कि ऑर्डर अभी नहीं है, और दोनों नई एंट्री जोड़ देंगे।
ऐसी स्थिति को रेस कंडीशन कहा जाता है। कोड में साधारण पहले से जाँच इससे पूरी तरह नहीं बचाती। डेटाबेस के स्तर पर सीमा के बिना जाँच की कमी यह है कि समानांतर लोड में वह टूट जाती है।
ऑर्डर सेव हो गया, लेकिन API का जवाब खो गया
अनुरोध कई चरणों से गुज़रता है: सर्वर डेटा पाता है, एंट्री बनाता है, टास्क क्यू में डालता है, जवाब भेजता है। इनमें से किसी के बीच भी गड़बड़ी हो सकती है। उदाहरण के लिए, डेटाबेस ने ऑर्डर बनना पहले ही पुष्ट कर दिया, लेकिन क्लाइंट को जवाब भेजने से पहले कनेक्शन टूट गया।
क्लाइंट नहीं जानता कि ऑर्डर स्वीकार हुआ या नहीं, और ऑपरेशन दोहराता है। अलग जाँच तंत्र के बिना API अनुरोध को नया मानता है। लॉग में यह अक्सर ऐसा दिखता है जैसे सेवा ने दो ऑर्डर «खुद» बनाए, जबकि उसके पास दो इनकमिंग कॉल थे।
ऑर्डर बनाने के लिए इडेम्पोटेंट कुंजी
बनाने के ऑपरेशन के लिए एक अनोखी इडेम्पोटेंसी कुंजी चाहिए। क्लाइंट इसे पहली बार भेजने से पहले जनरेट करता है और ऑर्डर के पैरामीटर के साथ भेजता है। टाइमआउट या एरर के कारण दोहराने पर वही कुंजी इस्तेमाल होती है।
API कुंजी को प्रोसेसिंग के नतीजे के साथ सेव करता है। अगर पहले से ज्ञात कुंजी वाला अनुरोध आता है, तो सर्वर नया ऑर्डर नहीं बनाता, बल्कि पहली कॉल का नतीजा लौटाता है: ऑर्डर का आईडी, उसकी स्थिति या पहले बनी गड़बड़ी।
एक कुंजी एक बिज़नेस ऑपरेशन से मेल खानी चाहिए, एक HTTP कनेक्शन से नहीं।
इस तरीक़े की कमी यह है कि कुंजियाँ सेव करनी होती हैं, नियमों के अनुसार साफ़ करनी होती हैं और API की ओर से जाँचनी होती हैं। अगर हर दोहराने पर नई कुंजी जनरेट हो, तो सुरक्षा काम नहीं करेगी। अगर अलग-अलग ऑर्डर के लिए एक ही कुंजी इस्तेमाल हो, तो कुछ नए ऑपरेशन ग़लती से अस्वीकार हो जाएँगे।
विशिष्टता डेटाबेस द्वारा नियंत्रित होनी चाहिए
इडेम्पोटेंसी को डेटाबेस में विशिष्टता की सीमा से पूरा करना बेहतर है। इसके लिए वह संयोजन चुना जाता है जो ऑर्डर को स्पष्ट रूप से बताता है: क्लाइंट का आंतरिक आईडी, इडेम्पोटेंसी कुंजी, सेवा का प्रकार और अन्य ज़रूरी फ़ील्ड।
डेटाबेस को दूसरी एंट्री अस्वीकार करनी चाहिए, भले ही दो हैंडलर एक साथ बनाने तक पहुँच गए हों। टकराव के बाद API मौजूदा ऑर्डर लौटाता है, बिना स्पष्टीकरण वाली गड़बड़ी नहीं।
सख़्त विशिष्टता सीमा की कमी यह है कि इसे केवल लिंक या username पर नहीं बनाया जा सकता। क्लाइंट जान-बूझकर उसी चैनल पर एक ही सेवा कई बार ऑर्डर कर सकता है। बहुत व्यापक सीमा सामान्य दोबारा ख़रीद को ब्लॉक कर देगी।
क्यू टास्क को एक से ज़्यादा बार पहुँचा सकता है
टास्क क्यू अक्सर «कम से कम एक बार डिलीवरी» के सिद्धांत पर काम करते हैं। अगर वर्कर ने टास्क प्रोसेस किया, लेकिन उसका पूरा होना पुष्ट करने से पहले ही, तो क्यू वही टास्क किसी दूसरे वर्कर को दोबारा दे सकता है।
क्यू के लिए यह टास्क न खोने का सामान्य तरीक़ा है। इडेम्पोटेंसी के बिना ऑर्डर बनाने के लिए यह डुप्लिकेट का स्रोत है। टास्क का आईडी या ऑपरेशन की अलग कुंजी अंतिम हैंडलर तक पहुँचनी चाहिए, जिसमें सप्लायर को ऑर्डर भेजने वाला मॉड्यूल भी शामिल है।
दोबारा डिलीवरी बंद करने की कमी यह है कि वर्कर के गिरने पर कुछ ऑर्डर खो सकते हैं। संभावित दोहराव स्वीकार करना और हैंडलर को उनके प्रति मज़बूत बनाना ज़्यादा सुरक्षित है।
डुप्लिकेट पैनल और सप्लायर के बीच बनते हैं
आंतरिक ऑर्डर एक बार बन सकता है, लेकिन बाहरी API को अनुरोध दो बार भेजा जा सकता है। कारण वही है: पैनल को सप्लायर से जवाब नहीं मिला और उसने भेजना दोहराने का फ़ैसला किया। अगर सप्लायर पहला अनुरोध पहले ही स्वीकार कर चुका है, तो उसकी ओर दो समान रिक्वेस्ट दिखेंगी।
आंतरिक ऑर्डर को बाहरी से जोड़ने के लिए अलग बाइंडिंग चाहिए: भेजने का आईडी, इडेम्पोटेंसी कुंजी या सप्लायर का सेव किया गया जवाब। यह नहीं माना जा सकता कि अपने पैनल में एंट्री पर सुरक्षा अपने आप आउटगोइंग कॉल की भी रक्षा करेगी।
किसी बाहरी API से मिलान की कमी यह है कि हर सप्लायर बाहरी कुंजी से खोज का समर्थन नहीं करता। तब भेजने के प्रयासों को दर्ज करना और अनिश्चित स्थितियों को अलग से जाँचना पड़ता है।
वेबहुक को नया ऑर्डर नहीं बनाना चाहिए
वेबहुक बदलावों की सूचना देते हैं: ऑर्डर स्वीकार हुआ, शुरू हुआ, पूरा हुआ, रद्द हुआ या जाँच चाहिए। गड़बड़ी तब होती है जब वेबहुक हैंडलर सूचना को ऑर्डर फिर से बनाने का आदेश मान लेता है।
वही वेबहुक दोबारा आ सकता है। भेजने वाला डिलीवरी दोहराता है अगर उसे पुष्टि नहीं मिली, और सूचनाएँ कभी-कभी क्रम से बाहर आती हैं। हैंडलर को बाहरी आईडी से मौजूदा ऑर्डर ढूँढना और स्थिति अपडेट करनी चाहिए।
वेबहुक को केवल प्राप्ति के समय से प्रोसेस करने की कमी यह है कि देर से आई सूचना वर्तमान स्थिति को पुरानी से ओवरराइट कर सकती है। इवेंट आईडी, स्थिति का वर्ज़न या स्पष्ट ट्रांज़िशन नियम चाहिए।
कौन-सी एंट्री डुप्लिकेट का स्रोत ढूँढने में मदद करेगी
जाँच के लिए केवल दो ऑर्डर नंबर देखना काफ़ी नहीं है। प्रोसेसिंग के हर चरण का डेटा चाहिए: अनुरोध का समय, इडेम्पोटेंसी कुंजी, क्लाइंट का आईडी, ऑर्डर के पैरामीटर, बैकग्राउंड टास्क का नंबर, बाहरी API का जवाब और दोबारा भेजने के प्रयास।
- डुप्लिकेट को केवल लिंक से नहीं, ऑपरेशन की कुंजी से मिलाएँ;
- जाँचें कि इनकमिंग API के लॉग में समान अनुरोध थे या नहीं;
- देखें कि क्यू में टास्क दोहराया गया या नहीं;
- आंतरिक ऑर्डर बनाने को सप्लायर को भेजने से अलग रखें;
- जवाब मिलने के तुरंत बाद रिक्वेस्ट की बाहरी आईडी सेव करें।
बहुत छोटे लॉग की कमी यह है कि समस्या का स्रोत जाँचे जाने से पहले ही गायब हो जाता है। बहुत ज़्यादा लॉगिंग की कमी यह है कि एंट्री में टोकन, व्यक्तिगत डेटा और अन्य संवेदनशील फ़ील्ड आ सकते हैं, इसलिए उन्हें मास्क करना चाहिए।
अनुरोध के अनिश्चित नतीजे को कैसे संभालें
टाइमआउट के बाद नए डेटा के साथ ऑर्डर तुरंत दोबारा नहीं बनाना चाहिए। पहले API को इडेम्पोटेंसी कुंजी या क्लाइंट आईडी से ऑपरेशन जाँचना चाहिए। अगर ऑर्डर मिल जाए, तो उसकी वर्तमान स्थिति लौटाई जाती है। अगर प्रोसेसिंग अभी चल रही है, तो क्लाइंट को प्रतीक्षा की स्थिति मिलती है।
- पहले अनुरोध से पहले ऑपरेशन की कुंजी बनाएँ।
- हर दोहराने पर वही कुंजी भेजें।
- कुंजी और ऑर्डर को डेटाबेस के एक ही सुरक्षित ऑपरेशन में सेव करें।
- ऑपरेशन का आईडी क्यू और बाहरी API तक पहुँचाएँ।
- दोबारा कॉल पर पहले बना ऑर्डर लौटाएँ।
ऐसे परिदृश्य के लिए API और क्लाइंट इंटीग्रेशन में सुधार चाहिए। इसकी कमी यह है कि डीबग करना ज़्यादा मुश्किल और ऑर्डर की स्थितियाँ ज़्यादा होती हैं, लेकिन अनुरोध की दोबारा डिलीवरी का अपने आप दोबारा ख़रीद होना बंद हो जाता है।
Last Articles
डिज़ाइन और कार्यक्षमता में क्या बदला हमने साइट को अपडेट किया है ताकि इसके साथ काम करना तेज़ और आसान हो। मुख्य बदलाव इंटरफ़ेस, व्यक्तिगत कैबिनेट और ऑर..
Good afternoon, I've collected all the news during this time.: 1. The main news is that prices for twitch viewers have been greatly reduced, while Tw..
1. हमारे सभी दर्शकों के लिए 15% छूट के लिए प्रोमो कोड "December2025" का उपयोग करें2. हमने 1 जनवरी तक अपने कॉन्फ़िगरेशन टूल और सबसे सस्ते दर्शक श्रेणी ..
चिकोटी सेवाएं हैं स्थिर रूप से काम करना, इसलिए हम दस्तों, पुनर्विक्रेताओं के साथ सहयोग करने के लिए तैयार हैं, सेवा मालिक, बॉट मालिक, और कई अन्य । ..
हम हमारी ट्विच व्यूअर सेवाओं को पूरी तरह से अपडेट कर दिया है, और वे अब हैं स्थिरतापूर्वक काम करना । हम केवल दर्शकों के लिए उच्च गुणवत्ता वाले आईप..
Hello everyone! Today, we are announcing a new feature—"Twitch Viewer Configurator". Now, you can customize any plan for your Twitch channel. Choo..
Greetings, I have compiled a guide for streamers, which will be very relevant at the moment. Now YouTube and twitch have disabled monetization from vi..
We have finally developed the APINow it will be more convenient for our partner sites to work with us.To update the maximum tariffs for YouTube, an up..
साझेदारी सेवाओं और रेफरल कार्यक्रम की भारी लोकप्रियता के कारण, हमने एक सहयोग तालिका बनाई है। सार बहुत सरल है: अधिक लाइव दर्शक - हमारी ओर से अधिक विज्ञ..
स्ट्रीमर्स के लिए हमारी सेवाएं
Shopee
Bigo
कंटेंट क्रिएटर्स के लिए हमारी सेवाएं
