🙅🏻 📕 💪 शानदार सलाहकार ताले और जहां वे रहते हैं 🤙 🍐 👩‍👩‍👧‍👧

PostgreSQL में सलाहकार ताले के लिए बहुत सुविधाजनक तंत्र है , वे सलाहकार ताले भी हैं । हम टेन्सर में सिस्टम में कई स्थानों पर उनका उपयोग करते हैं, लेकिन कुछ लोग विस्तार से समझते हैं कि वे कैसे काम करते हैं, और यदि गलत व्यवहार किया जाता है तो क्या समस्याएं हो सकती हैं ।

ताले के बारे में और पढ़ें

, , PostgreSQL.

सिफारिश ताले के लाभ

इस तंत्र और "साधारण" तालिका / पृष्ठ / रिकॉर्ड स्तर के ताले के बीच मूलभूत अंतर यह है कि कई प्रमुख विशेषताएं हैं।

कस्टम आईडी लॉक

पीजी में "सामान्य" ताले हमेशा एक विशिष्ट डेटाबेस ऑब्जेक्ट (टेबल, रिकॉर्ड, डेटा पेज) और कनेक्शन की सेवा करने वाली प्रक्रिया से बंधे होते हैं। सलाहकार ताले भी एक प्रक्रिया है, लेकिन एक वास्तविक वस्तु के बजाय, एक अमूर्त पहचानकर्ता को (bigint) या (पूर्णांक, पूर्णांक) के रूप में सेट किया जा सकता है ।

वैसे, प्रत्येक लॉक को एक प्रक्रिया में संलग्न करने का मतलब है कि pg_terminate_backend(pid)क्लाइंट पक्ष से कनेक्शन को सही तरीके से पूरा करना या उसके माध्यम से नामकरण करके , आप इसके द्वारा लगाए गए सभी ताले से छुटकारा पा सकते हैं।

लॉक कैप्चर के लिए कैस चेक करें

CAS एक तुलना-और-सेट है , अर्थात, कैप्चर क्षमता का सत्यापन और लॉक का कैप्चर स्वयं एक परमाणु संचालन के रूप में होता है, और जाहिर है कि कोई भी उनके बीच में नहीं लड़ सकता है।

यही है, यदि आप पहले pg_locks के लिए एक सत्यापन अनुरोध करते हैं , तो परिणाम देखें, फिर तय करें कि लॉक करना है या नहीं, तो कोई भी गारंटी नहीं देता है कि इन ऑपरेशनों के बीच कोई भी आपकी ज़रूरत की वस्तु लेने का प्रबंधन नहीं करेगा। लेकिन अगर आप pg_try_advisory_lock का उपयोग करते हैं , तो आप तुरंत इस लॉक को प्राप्त करेंगे, या फ़ंक्शन बस वापस आ जाएगा FALSE।

अपवादों और अपेक्षाओं के बिना कब्जा नहीं

"सामान्य" ताले मॉडल में मौजूद हैं "यदि आपने पहले से ही लॉक के लिए कहा है, तो प्रतीक्षा करें। आप प्रतीक्षा करने के लिए नहीं करना चाहता था, तो ( NOWAIT, statement_timeout, lock_timeout) - यहाँ एक अपवाद है " । यह दृष्टिकोण लेन-देन के भीतर बहुत हस्तक्षेप करता है, क्योंकि तब आपको या तो BEGIN-EXCEPTION-ENDप्रसंस्करण के लिए एक ब्लॉक को लागू करना होगा या ROLLBACKलेनदेन को वापस लेना होगा ।

इस व्यवहार से बचने का एकमात्र तरीका SELECT ... SKIP LOCKEDसंस्करण 9.5 के साथ आए डिजाइन का उपयोग करना है । दुर्भाग्य से, इस पद्धति के साथ, विकल्प "क्या करना है और क्या नहीं" और "पहले से ही अवरुद्ध है" अविवेच्य हो गया है।

की वजह से सिफारिश ताले कोशिश कार्यों बस लौटने TRUE/FALSE।

भ्रमित न हों pg_advisory_lockऔर - पहला फ़ंक्शन लॉक प्राप्त होने तक प्रतीक्षा करेगा , और दूसरा बस तुरंत वापस आ जाएगा यदि इसे "अभी" पकड़ना असंभव है।pg_try_advisory_lockFALSE

लेन-देन के भीतर और बाद में ताले

जैसा कि मैंने ऊपर उल्लेख किया है, ऑब्जेक्ट लॉक प्रक्रिया से "संलग्न" हैं और इसमें केवल वर्तमान लेनदेन के भाग के रूप में मौजूद हैं। यहां तक कि सिर्फ थोपना - सफल नहीं होगा:

LOCK TABLE tbl;
-- ERROR:  LOCK TABLE can only be used in transaction blocks

तदनुसार, लेनदेन के अंत में, उस पर लगाए गए सभी ताले हटा दिए जाते हैं। इसके विपरीत, सलाहकार ताले मूल रूप से ताले रखने और लेनदेन के दायरे से बाहर की क्षमता के साथ डिज़ाइन किए गए थे :

SELECT pg_advisory_lock(1);
SELECT * FROM pg_locks WHERE pid = pg_backend_pid() AND locktype = 'advisory';

-[ RECORD 1 ]------+--------------
locktype           | advisory
database           | 263911484
relation           |
page               |
tuple              |
virtualxid         |
transactionid      |
classid            | 0 <--  int4 #1    int8
objid              | 1 <--  int4 #2    int8
objsubid           | 1
virtualtransaction | 416/475768
pid                | 29264
mode               | ExclusiveLock
granted            | t
fastpath           | f

लेकिन पहले से ही संस्करण 9.1 से, सलाहकार कार्यों के xact संस्करण दिखाई दिए हैं जो आपको "साधारण" तालों के व्यवहार को लागू करने की अनुमति देते हैं जो स्वचालित रूप से जारी किए जाते हैं जब लेनदेन जो उन्हें लगाया जाता है वह पूरा हो जाता है।

वीएलएसआई में उपयोग के उदाहरण

वास्तव में, किसी भी अन्य लॉक की तरह, संसाधन संसाधन की विशिष्टता को सुनिश्चित करने के लिए सलाहकार की सेवा। हमारे देश में, ऐसे संसाधन आमतौर पर या तो पूरी तालिका या तालिका का एक विशिष्ट रिकॉर्ड होते हैं, जो किसी कारण से "लॉक" नहीं होना चाहते हैं।

कार्यकर्ता का मोनोप्रोसेसिंग

यदि डेटाबेस में कुछ डेटा को संसाधित करने की आवश्यकता एक बाहरी घटना से शुरू होती है, लेकिन मल्टीप्रोसेसिंग बेमानी है या दौड़ की स्थिति पैदा कर सकती है , तो इस डेटा पर एक बार में केवल एक ही प्रक्रिया करना उचित है ।

ऐसा करने के लिए, हम पहले पैरामीटर के रूप में टेबल पहचानकर्ता और दूसरे के रूप में विशिष्ट एप्लिकेशन प्रोसेसिंग आईडी के साथ लॉक करने का प्रयास करेंगे:

SELECT pg_try_advisory_lock(
  'processed_table'::regclass::oid
, -1 --   worker'
);

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

समवर्ती कतार प्रसंस्करण

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

इस मामले में, हम एक विशेष रिकॉर्ड के टेबल आईडी और पीके पर ताला लगाते हैं:

SELECT
  *
FROM
  queue_table
WHERE
  pg_try_advisory_lock('queue_table'::regclass::oid, pk_id)
ORDER BY
  pk_id
LIMIT 1;

यही है, प्रक्रिया तालिका से पहला रिकॉर्ड प्राप्त करेगी जो अभी तक अपने प्रतिस्पर्धी भाइयों द्वारा अवरुद्ध नहीं किया गया है।

हालांकि, यदि पीके (पूर्णांक) , लेकिन (पूर्णांक, पूर्णांक) शामिल नहीं है (उदाहरण के लिए समान लागत गणना में), तो आप इस जोड़ी पर सीधे लॉक लगा सकते हैं - यह संभावना नहीं है कि "प्रतियोगी" के साथ एक चौराहा होगा।

जरूरी! समय-समय पर ठीक से अपनी कतार तालिका बनाए रखना मत भूलना !

विशेष दस्तावेज़ प्रसंस्करण

इसका उपयोग दस्तावेज़ प्रबंधन समाधान में हर जगह किया जाता है । दरअसल, एक वितरित वेब-सिस्टम में एक और एक ही दस्तावेज़ को एक ही समय में अलग-अलग उपयोगकर्ताओं द्वारा देखने के लिए खोला जा सकता है, लेकिन इसे केवल एक बार किसी भी समय संसाधित किया जा सकता है (इसके राज्य आदि को बदल सकते हैं)।

पारंपरिक मुद्दे

उनके बिना कहाँ! लगभग सभी एक बात पर उबलते हैं : उन्होंने ताला नहीं खोला ।

एक सलाहकार लॉक का बहु-ओवरले

RTFM , जैसा कि वे कहते हैं:

यदि एक बार में अवरुद्ध करने के कई अनुरोध प्राप्त होते हैं, तो वे जमा हो जाते हैं, इसलिए यदि एक संसाधन को तीन बार अवरुद्ध किया गया है, तो इसे अन्य सत्रों में उपलब्ध होने के लिए तीन बार अनब्लॉक करने की आवश्यकता है ।

एक ही बार में बहुत सारे ताले लगाएं

उनमें से हजारों! मैनुअल को फिर से पढ़ें :

दोनों सलाहकार और नियमित ताले साझा मेमोरी क्षेत्र में संग्रहीत किए जाते हैं, जिनमें से आकार कॉन्फ़िगरेशन मापदंडों max_locks_per_transactionऔर द्वारा निर्धारित किया जाता है max_connections। यह महत्वपूर्ण है कि यह मेमोरी पर्याप्त है, क्योंकि अन्यथा सर्वर किसी भी लॉक को जारी करने में सक्षम नहीं होगा । इस प्रकार, अनुशंसित ताले की संख्या जो सर्वर जारी कर सकता है, आमतौर पर सर्वर कॉन्फ़िगरेशन के आधार पर दसियों या सैकड़ों हजारों तक सीमित होता है।

सामान्य तौर पर, यदि कोई स्थिति आती है जब आप कई हजार सलाहकार लॉक लगाना चाहते हैं (भले ही आप उन्हें बाद में सही तरीके से हटा दें) - बहुत मुश्किल से सोचें कि सर्वर के उठने पर आप कहां दौड़ेंगे।

रिकॉर्ड्स को छानते हुए लीक

यहां हम पिछले अनुरोध को लेते हैं और समरसता स्थिति जैसे कि समता चेक आईडी - जोड़ते हैं AND pk_id % 2 = 0। प्रत्येक प्रविष्टि के लिए दोनों स्थितियों की जाँच की जाएगी ! नतीजतन, यह pg_try_advisory_lockपूरा हो गया था , ताला सुपरिम्पोज किया गया था, और फिर रिकॉर्ड को समता द्वारा फ़िल्टर किया गया था ।

या मैनुअल से एक विकल्प:

SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- !

वह सब है - अवरोधक बना हुआ है , लेकिन हमें इसके बारे में पता नहीं है। यह सही अनुरोधों के साथ व्यवहार किया जाता है, सबसे खराब स्थिति में - pg_advisory_unlock_all।

ओह, भ्रमित!

शैली के क्लासिक्स ...

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

pg_try_advisory_lockpg_try_advisory_xact_lock

Pgbouncer के माध्यम से काम करें

यह कई के लिए दर्द का एक अलग स्रोत है, जब प्रदर्शन के लिए, डेटाबेस के साथ काम करना लेनदेन मोड में pgbouncer से गुजरता है ।

इसका मतलब यह है कि आपके दो पड़ोसी लेनदेन डेटाबेस से एक ही कनेक्शन पर चल रहे हैं (जो वास्तव में pgbouncer से गुजरता है) आधार पक्ष के विभिन्न "भौतिक" कनेक्शन में निष्पादित किया जा सकता है । और उनके अपने ताले हैं ... प्रत्येक के पास

कुछ विकल्प हैं:

या डेटाबेस से सीधे कनेक्शन के माध्यम से काम करने के लिए जाना
या एक एल्गोरिथ्म का आविष्कार करें ताकि सभी सलाहकार ताले केवल लेनदेन के भीतर हों (xact)

अभी के लिए इतना ही।

शानदार सलाहकार ताले और जहां वे रहते हैं