MySQL में लाते समय रो लॉकिंग

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







दिए गए:

1. घटना कतार
2. तथ्य यह है कि घटनाओं को जंजीरों में जोड़ा जा सकता है
3. तथ्य यह है कि घटनाओं "नई" घटनाओं उत्पन्न कर सकते हैं
4. प्रोसेसर ( डेमन ) जो इस कतार को संसाधित करता है (आवश्यक कक्षाओं को सम्मिलित करता है, पुस्तकालयों को लोड करता है, वह सब कुछ करता है जो घटना में किए जाने की आवश्यकता है) और कतार में प्रत्येक प्रविष्टि को "संसाधित" के रूप में चिह्नित करता है, एक लॉग लिखता है और काम करना जारी रखता है।
5. MySQL DBMS (इसलिए ऐतिहासिक रूप से)

अब तक, सब कुछ बहुत स्पष्ट है - श्रृंखला से फ़ील्ड्स के साथ कतार के लिए एक तालिका है: आईडी (int), event_id (int fk), event_data (blob), execute_at (datetime), निष्पादित /at (डेटाटाइम)। दानव एक समय में एक घटना लेता है और अपना बुरा काम करता है :)



लेकिन अब हमारी परियोजना विकसित हो गई है और सिस्टम में अधिक उपयोगकर्ता, क्लस्टर में अधिक मशीनें, और क्रमशः कतार में अधिक नौकरियां हैं। उपयोगकर्ता "3 सेकंड" प्रतीक्षा करते हैं जब तक कि दानव श्रृंखला के अगले चरण को संसाधित करने के लिए नहीं देता है, यह टूट गया और वे और अधिक प्रदर्शन के लिए भीख मांगने लगे। समर्थन "टोर और मेटल" और अंत में कई और प्रोसेसर लॉन्च करने का फैसला किया।



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

 अगर (घटना = db.select ("कतार से आईडी का चयन करें जहां लॉक = 'गलत' और निष्पादित करें <अब () लिमिट 1")) {
 db.execute ("अपडेट कतार सेट लॉक = 'सत्य' जहां id =" + event.id);
 [...]
 }

और सब कुछ ठीक हो जाएगा यदि सिस्टम अल्ट्रा-फुलाया मशीनों के एक क्लस्टर पर नहीं बनाया गया था, और अगर लगभग 100 राक्षस "अंतरिक्ष" में सक्रिय नहीं थे। पहली और दूसरी एसक्यूएल क्वेरी के बीच, जैसा कि अभ्यास ने दिखाया है, कई और राक्षसों को "पच्चर" देना आसान था और एक ही कार्य पर काम करना शुरू कर दिया। यदि हम इस विचार से आगे बढ़ते हैं कि एक कार्य नए लोगों को "कास्ट" कर सकता है, तो कुछ दिनों के बाद कतार में निष्पादन के लिए 1,000,000+ कार्य हो सकते हैं, और सर्वर पर लॉग उपयोग करने योग्य स्थान के 10 हेक्टेयर से अधिक हो जाएंगे। जीने के लिए कितना पुराना है!



किसे दोष देना है? क्या करें? लेन-देन वांछित परिणाम नहीं देते हैं। कैसे जीना है? किसको हराएं? कौन मेरे हाथ फाड़ दे?



और हमें वास्तव में क्या चाहिए? लेकिन यह आवश्यक है कि DBMS स्वचालित रूप से उन ROW को ब्लॉक कर देता है जिनसे चयन अन्य प्रक्रियाओं के लिए किया जाता है (तालिका को ब्लॉक करें - प्रस्ताव न दें)। यही है, ताकि अन्य शैतान बस उस पंक्ति को न देखें जो मेरे नमूने में गिर गई थी।



और क्या? और कैसे? और वह सब प्राथमिक है, MySQL में UPDATE कंस्ट्रक्शन के लिए एक सेलेक्ट * FROM टेबल है - जो बस यही करता है। तदनुसार, हम निम्नलिखित के बारे में प्रसंस्करण कोड के एक टुकड़े को फिर से लिखते हैं:

 db.execute ("ट्रांसपोर्टेशन स्टार्ट");
 अगर (घटना = db.select ("कतार से आईडी का चयन करें जहां लॉक = 'गलत' और निष्पादित करें <अब () अपडेट 1 के लिए सीमा")) {
 [...]
 }
 db.execute ("COMMIT");

यही सब प्यार है!



ps सावधान! यह सब केवल InnoDB जैसे तालिकाओं पर काम करता है!