🙏🏿 💾 ⛲️ रूबी एग्जेक्युटिव्स की चुप्पी: ट्रांजेक्शनल रेल / पोस्टग्रेक्सेल थ्रिलर 🈺 🙇🏽 🤱🏻

यह इस बारे में एक कहानी है कि जब आप किसी डेटाबेस में लेन-देन के अंदर होते हैं, तो आपको त्रुटियों की अनदेखी क्यों नहीं करनी चाहिए । यह पता लगाना कि लेन-देन का सही उपयोग कैसे किया जाए और उनका उपयोग करते समय क्या किया जाए, यह विकल्प नहीं है। Spoiler: यह PostgreSQL में सलाहकार ताले के बारे में होगा!

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

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

इससे कोई फर्क नहीं पड़ता कि उपयोगकर्ता द्वारा आयात को रद्द कर दिया गया था या पूरी तरह से स्वयं द्वारा - किसी भी मामले में, कार्यों की अनुपस्थिति का मतलब है कि सब कुछ खत्म हो गया है और उपयोगकर्ता एप्लिकेशन का उपयोग करना शुरू कर सकता है।

डिजाइन सरल और विश्वसनीय है, लेकिन इसमें एक छोटा बग था। उनके बारे में एक सामान्य बग रिपोर्ट थी: “आयात रद्द होने के बाद, उपयोगकर्ता को उसके सामानों की एक सूची दिखाई जाती है। हालांकि, यदि आप पृष्ठ को ताज़ा करते हैं, तो उत्पादों की सूची कई प्रविष्टियों द्वारा पूरक है। " इस व्यवहार का कारण सरल है - जब उपयोगकर्ता ने "रद्द करें" बटन पर क्लिक किया, तो उसे तुरंत सभी उत्पादों की सूची में स्थानांतरित कर दिया गया। लेकिन इस समय, पहले से ही कुछ सामानों का आयात शुरू हो चुका है।

यह, ज़ाहिर है, एक तिपहिया है, लेकिन उपयोगकर्ताओं को आदेश द्वारा हैरान किया गया था, इसलिए इसे ठीक करना अच्छा होगा। मेरे पास दो तरीके थे: किसी तरह की पहचान करना और पहले से ही चल रहे कार्यों को "मारना", या जब मैं रद्द बटन दबाता हूं, तब तक प्रतीक्षा करें जब तक कि वे पूरा न हो जाएं और उपयोगकर्ता को और स्थानांतरित करने से पहले "खुद की मृत्यु" न करें। मैंने दूसरा रास्ता चुना - प्रतीक्षा करने का।

लेन-देन ताले बचाव के लिए भागते हैं

(रिलेशनल) डेटाबेस के साथ काम करने वाले सभी लोगों के लिए, इसका उत्तर स्पष्ट है: लेनदेन का उपयोग करें !

यह याद रखना महत्वपूर्ण है कि अधिकांश आरडीबीएमएस में, लेन-देन के भीतर अपडेट किए गए रिकॉर्ड ब्लॉक किए जाएंगे और जब तक यह लेन-देन पूरा नहीं हो जाता, तब तक अन्य प्रक्रियाओं के परिवर्तन के लिए दुर्गम। सेलेक्ट SELECT FOR UPDATE का उपयोग करके चुने गए रिकॉर्ड को भी लॉक कर दिया जाएगा।

बिल्कुल हमारे मामले! मैंने अलग-अलग सामानों को एक लेन-देन में आयात करने के कार्य को लपेटा और शुरुआत में ही कार्य रिकॉर्ड को अवरुद्ध कर दिया:

 ActiveRecord::Base.transaction do task = Import::Task.lock.find_by(id: id) # SELECT … FOR UPDATE  «    » return unless task #  - ? ,    ! #     task.destroy end

अब, जब उपयोगकर्ता आयात को रद्द करना चाहता है, तो आयात रोक संचालन उन आयातों के कार्यों को हटा देगा जो अभी तक शुरू नहीं हुए हैं और पहले से मौजूद लोगों के पूरा होने का इंतजार करने के लिए मजबूर होंगे:

 user.import_tasks.delete_all #

सरल और सुरुचिपूर्ण! मैंने परीक्षण चलाए, स्थानीय स्तर पर और मंचन में आयात की जाँच की, और "लड़ाई में" तैनात किया।

इतनी जल्दी नहीं ...

अपने काम से संतुष्ट, मैं जल्द ही बग रिपोर्ट और लॉग में त्रुटियों के टन को खोजने के लिए बहुत आश्चर्यचकित था। कई उत्पादों का आयात नहीं किया गया था । कुछ मामलों में, सभी आयातों के पूरा होने के बाद केवल एक ही उत्पाद रह सकता है।

लॉग में त्रुटियां या तो उत्साहजनक नहीं थीं: PG::InFailedSqlTransaction एक बैकट्रैक के साथ उस कोड की ओर जाता है जिसने निर्दोष SELECT एस को निष्पादित किया है। आखिर हो क्या रहा है?

डिबगिंग के एक दिन के बाद, मैंने समस्याओं के तीन मुख्य कारणों की पहचान की:

डेटाबेस में परस्पर विरोधी रिकॉर्डों की प्रतिस्पर्धी प्रविष्टि।
त्रुटियों के बाद PostgreSQL में स्वचालित लेनदेन रद्द करना।
आवेदन कोड में समस्याओं की चुप्पी (रूबी अपवाद)।

समस्या एक: संघर्षपूर्ण प्रविष्टियों का प्रतियोगी सम्मिलन

चूंकि प्रत्येक आयात ऑपरेशन में एक मिनट तक का समय लगता है और इनमें से कई कार्य होते हैं, इसलिए हम समय बचाने के लिए इनका समानांतर प्रदर्शन करते हैं। माल के आश्रित रिकॉर्ड इस हद तक प्रतिच्छेद कर सकते हैं कि उपयोगकर्ता के सभी उत्पाद एक बार में बनाए गए और फिर से उपयोग किए गए एक एकल रिकॉर्ड का उल्लेख कर सकते हैं।

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

समस्या दो: त्रुटियों के बाद PostgreSQL स्वचालित लेन-देन रद्द करना

बेशक, हमने डेटाबेस स्तर पर डीडीएल का उपयोग करके डुप्लिकेट कार्यों के निर्माण को रोका:

 ALTER TABLE product_deps ADD UNIQUE (user_id, characteristics);

यदि लेन-देन प्रगति में है तो एक नया रिकॉर्ड डाला जाएगा और लेनदेन B उपयोगकर्ता_आईडी और characteristics फ़ील्ड के समान मानों के साथ रिकॉर्ड सम्मिलित करने का प्रयास करेगा, लेनदेन B को एक त्रुटि प्राप्त होगी:

 BEGIN; INSERT INTO product_deps (user_id, characteristics) VALUES (1, '{"same": "value"}'); -- Now it will block until first transaction will be finished ERROR: duplicate key value violates unique constraint "product_deps_user_id_characteristics_key" DETAIL: Key (user_id, characteristics)=(1, {"same": "value"}) already exists. -- And will throw an error when first transaction have commited and it is become clear that we have a conflict

लेकिन एक विशेषता है जिसे नहीं भूलना चाहिए - लेनदेन बी, एक त्रुटि का पता लगाने के बाद, स्वचालित रूप से रद्द कर दिया जाएगा और इसमें किए गए सभी काम नाली के नीचे जाएंगे। हालाँकि, यह लेन-देन अभी भी एक "गलत" स्थिति में खुला है, लेकिन किसी भी, यहां तक कि सबसे हानिरहित अनुरोध को निष्पादित करने के प्रयास के साथ, केवल त्रुटियों को प्रतिक्रिया में वापस किया जाएगा:

 SELECT * FROM products; ERROR: current transaction is aborted, commands ignored until end of transaction block

खैर, यह कहना पूरी तरह से अनावश्यक है कि इस लेनदेन में डेटाबेस में दर्ज की गई हर चीज को बचाया नहीं जाएगा:

 COMMIT; --      ,   ROLLBACK --

समस्या तीन: मौन

इस बिंदु तक, यह पहले से ही स्पष्ट था कि बस आवेदन में लेनदेन जोड़ने से इसे तोड़ दिया गया। कोई विकल्प नहीं था: मुझे आयात कोड में गोता लगाना पड़ा। कोड में, बहुत बार निम्नलिखित पैटर्न मेरी आंख को पकड़ने लगे:

 def process_stuff(data) # ,   rescue StandardError nil #  ,  end

यहां कोड लेखक हमें बताता है: "हमने कोशिश की, हम सफल नहीं हुए, लेकिन यह ठीक है, हम इसके बिना जारी रखते हैं।" और यद्यपि इस पसंद के कारण काफी स्पष्ट हो सकते हैं (आवेदन स्तर पर सब कुछ संसाधित नहीं किया जा सकता है), यह वही है जो लेनदेन के आधार पर किसी भी तर्क को असंभव बनाता है: एक फेंका हुआ निष्पादन transaction ब्लॉक तक नहीं जा सकेगा, और एक सही रोलबैक का कारण नहीं होगा। लेनदेन (ActiveRecord इस ब्लॉक में सभी त्रुटियों को पकड़ता है, लेन-देन वापस करता है और उन्हें फिर से फेंकता है)।

एकदम सही तूफान

और इस तरह से ये तीनों कारक एक साथ परिपूर्ण बनाने के लिए आए ~~तूफान~~ बग:

लेनदेन में एक एप्लिकेशन डेटाबेस में एक परस्पर विरोधी रिकॉर्ड डालने की कोशिश करता है और PostgreSQL से "डुप्लिकेट कुंजी" त्रुटि का कारण बनता है। हालाँकि, इस त्रुटि के कारण लेन-देन को एप्लिकेशन में वापस नहीं लाया जाता है, क्योंकि यह एप्लिकेशन के किसी एक भाग के अंदर "hushed" होता है।
लेन-देन अमान्य हो जाता है, लेकिन एप्लिकेशन को इसके बारे में नहीं पता है और काम करना जारी है। डेटाबेस तक पहुंचने के किसी भी प्रयास में, एप्लिकेशन को फिर से एक त्रुटि मिलती है, इस बार "वर्तमान लेनदेन समाप्त हो गया है", लेकिन इस त्रुटि को भी बाहर निकाला जा सकता है ...
आप शायद पहले से ही समझ गए थे कि एप्लिकेशन में कुछ टूटना जारी है, लेकिन किसी को भी इसके बारे में तब तक पता नहीं चलेगा जब तक कि निष्पादन पहले स्थान पर नहीं पहुंच जाता है, जहां कोई अत्यधिक लालची rescue नहीं होता है और जहां त्रुटि अंततः पॉप अप हो सकती है, लॉग इन करें, त्रुटि ट्रैकर में पंजीकृत - कुछ भी। लेकिन यह जगह पहले से ही उस जगह से बहुत दूर होगी जो त्रुटि का मूल कारण बन गया है, और यह अकेले डिबगिंग को बुरे सपने में बदल देगा।

PostgreSQL में लेन-देन के ताले के लिए वैकल्पिक

आवेदन कोड में rescue लिए शिकार करना और सभी आयात तर्क को फिर से लिखना एक विकल्प नहीं है। एक लंबा समय। मुझे एक त्वरित समाधान की आवश्यकता थी और इसे पोस्टग्रेज पर पाया गया! इसमें तालों के लिए बिल्ट-इन समाधान है, लेन-देन में रिकॉर्ड को लॉक करने का विकल्प है, बैठक-सत्र-सलाहकार ताले। मैंने उन्हें निम्नानुसार इस्तेमाल किया:

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

फिर, प्रत्येक आयात ऑपरेशन में, मैं संपूर्ण आयात के लिए कुछ अद्वितीय कुंजी पर एक साझा लॉक लेता हूं (उदाहरण के लिए, उपयोगकर्ता आईडी और ऑपरेशन वर्ग के नाम से हैश):

 SELECT pg_advisory_lock_shared(42, user.id);

एक ही कुंजी पर साझा किए गए ताले को एक साथ किसी भी संख्या में सत्रों द्वारा लिया जा सकता है।

एक ही समय में आयात कार्रवाई को रद्द करने से डेटाबेस से सभी कार्य प्रविष्टियों को हटा दिया जाता है और उसी कुंजी पर एक विशेष लॉक लेने की कोशिश की जाती है। इस मामले में, उसे तब तक इंतजार करना होगा जब तक कि सभी साझा ताले जारी नहीं हो जाते:

 SELECT pg_advisory_lock(42, user.id)

और वह सब है! अब "रद्दीकरण" तब तक इंतजार करेगा जब तक कि व्यक्तिगत वस्तुओं के सभी "चल रहे" आयात पूरे नहीं हो जाते।

इसके अलावा, अब जब हम लेन-देन से नहीं जुड़े हैं, तो हम आयात रद्द करने के लिए प्रतीक्षा समय को सीमित करने के लिए एक छोटी सी हैक का उपयोग कर सकते हैं (यदि कुछ आयात "चिपक जाता है"), क्योंकि यह लंबे समय के लिए वेब सर्वर प्रवाह को अवरुद्ध करने के लिए अच्छा नहीं है (और बल उपयोगकर्ता की प्रतीक्षा करें):

 transaction do execute("SET LOCAL lock_timeout = '30s'") execute("SELECT pg_advisory_lock(42, user.id)") rescue ActiveRecord::LockWaitTimeout nil #    (     ) end

transaction ब्लॉक के बाहर त्रुटि को पकड़ना सुरक्षित है, क्योंकि ActiveRecord पहले से ही लेन-देन को वापस ले लेगा ।

लेकिन समान रिकॉर्ड के प्रतिस्पर्धी सम्मिलन के साथ क्या करना है?

दुर्भाग्य से, मैं एक समाधान नहीं जानता हूं जो प्रतिस्पर्धी आवेषण के साथ अच्छी तरह से काम करेगा। निम्नलिखित दृष्टिकोण हैं, लेकिन लेन-देन के पहले पूरा होने तक वे सभी समवर्ती आवेषणों को अवरुद्ध करेंगे:

INSERT … ON CONFLICT UPDATE दूसरे लेन-देन में INSERT … ON CONFLICT UPDATE (पोस्टग्रेक्यूस 9.5 के बाद से उपलब्ध) को तब तक लॉक किया जाएगा जब तक कि पहला लेन-देन पूरा नहीं हो जाता है और फिर वह रिकॉर्ड वापस कर देगा जो पहले लेनदेन द्वारा डाला गया था।
एक नया रिकॉर्ड सम्मिलित करने के लिए सत्यापन चलाने से पहले एक लेनदेन में कुछ सामान्य रिकॉर्ड को लॉक करें। यहां हम तब तक प्रतीक्षा करेंगे जब तक कि किसी अन्य लेनदेन में डाला गया रिकॉर्ड दिखाई न दे और सत्यापन पूरी तरह से काम न कर सके।
किसी प्रकार की सामान्य अनुशंसा लॉक लें - यह प्रभाव सामान्य रिकॉर्ड को अवरुद्ध करने के समान है।

ठीक है, अगर आप आधार स्तर की त्रुटियों के साथ काम करने से डरते नहीं हैं, तो आप सिर्फ विशिष्टता की त्रुटि पकड़ सकते हैं:

 def import_all_the_things #   ,   Dep.create(user_id, chars) rescue ActiveRecord::RecordNotUnique retry end

बस यह सुनिश्चित करें कि यह कोड अब लेन-देन में नहीं लिपटे।

वे अवरुद्ध क्यों हैं?

UNIQUE और EXCLUDE एक ही समय में रिकॉर्ड होने से रोककर संभावित संघर्षों को रोकते हैं। उदाहरण के लिए, यदि आपके पास एक पूर्णांक स्तंभ पर एक अद्वितीय बाधा है और एक लेनदेन 5 के मान के साथ एक पंक्ति सम्मिलित करता है, तो अन्य लेनदेन जो 5 सम्मिलित करने का प्रयास करते हैं, वे अवरुद्ध हो जाएंगे, लेकिन 6 या 4 को सम्मिलित करने का प्रयास करने वाले लेनदेन बिना अवरुद्ध किए तुरंत सफल होंगे। चूंकि PostgreSQL का न्यूनतम वास्तविक लेन-देन अलगाव स्तर READ COMMITED , इसलिए कोई लेन-देन अन्य लेन-देन से READ COMMITED परिवर्तनों को देखने का हकदार नहीं है। इसलिए, एक परस्पर विरोधी मूल्य के साथ एक INSERT को तब तक स्वीकार या अस्वीकार नहीं किया जा सकता जब तक कि पहला लेन-देन अपने परिवर्तनों को शुरू नहीं करता (तब दूसरा एक विशिष्टता त्रुटि प्राप्त करता है) या वापस रोल करता है (फिर दूसरे लेनदेन में सम्मिलित सफल होगा)। EXCLUDE प्रतिबंध के लेखक द्वारा एक लेख में इसके बारे में और पढ़ें।

भविष्य की आपदा को रोकें

अब आप जानते हैं कि सभी कोड लेनदेन में नहीं लपेटे जा सकते। यह सुनिश्चित करना अच्छा होगा कि भविष्य में मेरी गलती को दोहराते हुए कोई भी व्यक्ति इस तरह के कोड को लेनदेन में शामिल न करे।

ऐसा करने के लिए, आप अपने सभी ऑपरेशनों को एक छोटे सहायक मॉड्यूल में लपेट सकते हैं जो यह जांच करेगा कि लिपटे ऑपरेशन कोड को चलाने से पहले लेन-देन खुला है या नहीं (यहाँ यह माना जाता है कि आपके सभी ऑपरेशनों का इंटरफ़ेस समान है - call विधि)।

 #     module NoTransactionAllowed class InTransactionError < RuntimeError; end def call(*) return super unless in_transaction? raise InTransactionError, "#{self.class.name} doesn't work reliably within a DB transaction" end def in_transaction? connection = ApplicationRecord.connection # service transactions (tests and database_cleaner) are not joinable connection.transaction_open? && connection.current_transaction.joinable? end end #    class Deps::Import < BaseService prepend NoTransactionAllowed def call do_import rescue ActiveRecord::RecordNotUnique retry end end

अब, यदि कोई लेन-देन में किसी खतरनाक सेवा को लपेटने की कोशिश करता है, तो उसे तुरंत एक त्रुटि मिलेगी (जब तक कि, निश्चित रूप से, वह इसे चुप नहीं रखता)।

परिणाम

सीखा जाने वाला मुख्य सबक: अपवादों से सावधान रहें। एक पंक्ति में सब कुछ न संभालें, केवल उन अपवादों को पकड़ें जिन्हें आप जानते हैं कि कैसे संभालना है और बाकी लोगों को लॉग करने दें। कभी भी अपवादों को अनदेखा न करें (केवल अगर आप 100% सुनिश्चित नहीं हैं कि आप ऐसा क्यों कर रहे हैं)। जितनी जल्दी कोई त्रुटि दिखाई देती है, डिबग करना उतना ही आसान होगा।

और डेटाबेस में लेनदेन के साथ इसे ज़्यादा मत करो। यह रामबाण नहीं है। हमारे रत्नों को अलग करने वाले और after_commit_everywhere का उपयोग करें - वे आपके लेनदेन को पूरी तरह से मूर्ख बनाने में मदद करेंगे।

क्या पढ़ना है?

अवधी ग्रिम द्वारा असाधारण रूबी । यह लघु पुस्तक आपको सिखाएगी कि रूबी में मौजूदा अपवादों से कैसे निपटें और अपने आवेदन के लिए अपवाद प्रणाली को कैसे ठीक से डिज़ाइन करें।

@Brandur द्वारा एक परमाणु एपीआई को शक्ति के लिए परमाणु लेनदेन का उपयोग करना । उनके ब्लॉग में एप्लिकेशन विश्वसनीयता, रूबी और पोस्टग्रेक्यूएल के बारे में कई उपयोगी लेख हैं।

रूबी एग्जेक्युटिव्स की चुप्पी: ट्रांजेक्शनल रेल / पोस्टग्रेक्सेल थ्रिलर