😗 💨 📦 माइग्रेट फ़ोटो या MySQL में एक और कतार 👲🏿 🚥 👩🏾‍🎓

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

समस्या का बयान

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

कार्यान्वयन

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

CREATE TABLE MigrationPhoto ( user_id INT PRIMARY KEY, updated TIMESTAMP, photoserver VARCHAR(255), #  c   script_name VARCHAR(255), #  ,   done TINYINT(1), # 1    ,  0 KEY photoserver (photoserver), KEY script_name (script_name) )

सबसे पहले, उन सभी उपयोगकर्ताओं को जोड़ें जिनकी फ़ोटो हम अपनी तालिका में स्थानांतरित करना चाहते हैं:

 INSERT INTO MigrationPhoto (user_id,photoserver) VALUES (00000000, 'photoserver1')

पीसीएनएल एक्सटेंशन का उपयोग करके कुल प्रक्रियाओं पर प्रतिबंध आसानी से प्राप्त किया जाता है और यह बहुत रुचि नहीं है, इसलिए, हम आगे की प्रक्रिया को हस्तांतरण से निपटने पर विचार करेंगे।
हमें प्रति फोटो सर्वर के लिए एक विशिष्ट संख्या प्रदान करने की आवश्यकता है। सबसे पहले, आइए जानें कि कौन से फोटो सर्वर से कौन से उपयोगकर्ता कतार में हैं। हर बार सेलेक्ट फोटोजर्वर, COUNT (*) से न करने के लिए, हम एक अलग टेबल बनाएंगे :

 CREATE TABLE MigrationPhotoCounters ( photoserver VARCHAR(255) PRIMARY KEY, users INT )

प्रत्येक उपयोगकर्ता माइग्रेशनफ़ोटो तालिका में सम्मिलित होने पर हम इसे पॉप्युलेट करेंगे:

 INSERT INTO MigrationPhotoCounters (photoserver, users) VALUES ('photoserver1', 1) ON DUPLICATE KEY UPDATE users = users + VALUES(users)

या, माइग्रेशनफ़ोटो भरने के बाद, यह करें:

 INSERT INTO MigrationPhotoCounters (bphotos_server, users) VALUES (SELECT photoserver, COUNT(*) AS users FROM MigrationPhoto)

ऐसी तालिका होने के बाद, प्रत्येक प्रक्रिया की शुरुआत में हम करेंगे

 SELECT photoserver FROM MigrationPhotoCounters WHERE users>0 ORDER BY RAND()

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

 $processNumber = null; foreach ($photoservers as $serverName) { for ($i = 1; $i <= PROCESSES_PER_SERVER; $i++) { $lock = executeQuery("SELECT GET_LOCK('migration" . $serverName . '_' . $processNumber . "', 0)"); if ($lock === '1') { $processNumber = $i; break; } } if ($processNumber) { $serverName = $serverName; $scriptName = 'migration' . $serverName . '_' . $processNumber; break; } }

इस प्रकार, हम दो नेस्टेड चक्रों के माध्यम से सभी फोटो सर्वर और उनके लिए प्रक्रिया संख्याओं को क्रमबद्ध करते हैं। यदि आंतरिक लूप के सभी पुनरावृत्तियों को पूरा किया जाता है और $ प्रक्रियानंबर चर को परिभाषित नहीं किया जाता है, तो इस फोटो सर्वर के लिए प्रक्रियाओं की संख्या की सीमा पूरी हो गई है । यदि बाहरी लूप के सभी पुनरावृत्तियों को पूरा किया जाता है, तो यह सीमा सभी फोटो सर्वरों के लिए पहुंच गई है, जो अभी भी उपयोगकर्ताओं को माइग्रेट करना है।
मान लीजिए कि हमने फोटोसेवर 1 चुना, और यह इसके लिए दूसरी प्रक्रिया है, अर्थात, प्रक्रिया पहचानकर्ता $ scriptName = 'mig_photoserver1_2' होगा ।
आगे बढ़ने से पहले, उन उपयोगकर्ताओं की सामान्य कतार पर लौटते हैं, जो एक कारण या किसी अन्य के लिए, पिछले लॉन्च के दौरान हमारी पसंद की प्रक्रिया पहचानकर्ता ($ scriptName) के साथ टैग किए गए:

 UPDATE MIgrationPhoto SET script_name = NULL WHERE done = 0 AND script_name = 'migration_photoserver1_2'

हम इस प्रक्रिया द्वारा संसाधित किए गए उपयोगकर्ताओं के हिस्से को चिह्नित करते हैं:

 UPDATE SET MigrationPhoto script_name='migration_photoserver1_2' WHERE photoserver='photoserver1' AND done = 0 AND script_name IS NULL LIMIT 100;

अब हम उस कतार से कई उपयोगकर्ताओं को लेंगे जो हमारे द्वारा चुने गए फोटो सर्वर के अनुरूप हैं और अभी तक किसी अन्य प्रक्रिया से संसाधित नहीं हुए हैं:

 SELECT * FROM MigrationPhoto WHERE script_name='migration_photoserver1_2' AND done=0;

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

 UPDATE MigrationPhoto SET updated=NOW() WHERE user_id = 00000000

हम उन सभी ऑपरेशनों को करते हैं जिनकी हमें ज़रूरत है, सरलीकृत तरीके से उन्हें rsync के रूप में दर्शाया जा सकता है। फ़ोटो को सफलतापूर्वक स्थानांतरित करने के बाद, हमें इसे डेटाबेस में (प्रत्येक चयनित उपयोगकर्ताओं के लिए) नोट करने की आवश्यकता है:

 BEGIN; UPDATE MigrationPhotoCounters SET users = users - 1 WHERE photoserver = 'photoserver1'; UPDATE MigrationPhoto SET done = 1 WHERE user_id = 00000000; COMMIT;

ऐसा हो सकता है कि प्रसंस्करण के लिए उठाए गए 100 उपयोगकर्ताओं में से कुछ विभिन्न कारणों से हस्तांतरण नहीं कर पाएंगे। बाद में उन्हें स्थानांतरित करने के लिए इन उपयोगकर्ताओं को कतार में लौटना होगा:

 UPDATE MigrationPhoto SET script_name = NULL WHERE user_id IN (<failed_ids>)

हम इस प्रक्रिया को पूरा करते हैं:

 SELECT RELEASE_LOCK('migration_photoserver1_2')

ऐसा लगता है कि यह समाप्त हो सकता है। लेकिन हमारी योजना में एक मौलिक दोष है।
मान लीजिए कि एक प्रक्रिया शुरू हो गई है जिसमें $ scriptName = 'mig_photoserver1_10' है , जबकि PROCESSES_PER_SERVER = 10 । और यह प्रक्रिया गिर गई, उपयोगकर्ताओं को यह कतार में नहीं लौटने पर। इन उपयोगकर्ताओं को फिर से चुने जाने के लिए, या तो समान स्क्रिप्ट स्क्रिप्ट के साथ प्रक्रिया फिर से शुरू करनी होगी, या किसी को इन उपयोगकर्ताओं को डेटाबेस script_name = NULL में सेट करना होगा। उसी $ स्क्रिप्टनाम के साथ एक प्रक्रिया शुरू करना अब नहीं हो सकता है।
उदाहरण के लिए, हमारे पास माइग्रेशन फ़ोटोफ़ाउंटर्स में 100 फ़ोटोग्राफ़र हैं, प्रक्रियाओं की कुल संख्या की सीमा 50 है, प्रक्रियाओं की संख्या पर सीमा एक - 10 है, तो यह स्पष्ट है कि यदि किसी बिंदु पर एक फोटो सर्वर पर 10 प्रक्रियाएं थीं, तो भविष्य में यह फोटो सर्वर प्राप्त कर सकता है। केवल एक प्रक्रिया। इसलिए, हम एक और स्क्रिप्ट लिखेंगे, उदाहरण के लिए, एक बार एक मिनट script_name = उन उपयोगकर्ताओं के लिए NULL सेट करेगा, जिनकी प्रक्रियाएँ अभी चल रही हैं:

 foreach ($photoservers as $serverName) { for ($i = 1; $i <= PROCESSES_PER_SERVER; $i++) { $lock = executeQuery("SELECT GET_LOCK('migration" . $serverName . '_' . $processNumber . "', 0)"); if ($lock === '1') { executeQuery("UPDATE MigrationPhoto SET script_name = NULL WHERE done = 0 AND script_name = 'migration" . $serverName . '_' . $processNumber . "'"); } } }

अब, भले ही एक प्रक्रिया दुर्घटनाग्रस्त हो जाए, इसके उपयोगकर्ता अन्य प्रक्रियाओं द्वारा प्रसंस्करण के लिए उपलब्ध हो जाएंगे। इसके अलावा, यह "फ़्लाई पर" एक फोटो सर्वर प्रति प्रक्रियाओं की संख्या की सीमा को बदलने की अनुमति देगा।
जब प्रक्रिया पूरी हो जाती है और अन्य सभी उपयोगकर्ता डेटा का माइग्रेशन शुरू हो जाता है, तो यह सत्यापित करने के लिए पर्याप्त है कि माइग्रेशनफ़ोटो टेबल के अद्यतन क्षेत्र में निर्दिष्ट समय के बाद से उपयोगकर्ता की फ़ोटो नहीं बदली गई है। और अगर वे बदल गए, तो बस rsync दोहराएं। इसमें अधिक समय नहीं लगेगा, क्योंकि लगभग कोई भी उपयोगकर्ता 2-3 दिनों में अपनी सभी तस्वीरें नहीं बदलता है।
परिणामस्वरूप, हमारे पास 63 फोटो सर्वर थे जिसमें से हम फोटो पढ़ते हैं, और 30 सर्वर जिस पर हमने लिखा था। यह सब 80 प्रक्रियाओं द्वारा हुआ, जिसमें प्रति फोटो सर्वर में 3 से अधिक प्रक्रियाओं की सीमा नहीं थी। इन प्रतिबंधों के साथ, यातायात 150 एमबीपीएस था। थाईलैंड के उपयोगकर्ताओं के लिए तस्वीरें स्थानांतरित करना तीन दिनों से थोड़ा कम समय लगा। डेटा की मात्रा को देखते हुए, हमें एक उत्कृष्ट परिणाम मिला।

निष्कर्ष

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

एंटोन स्टेपानेंको, टीम लीड, पीएचपी डेवलपर

माइग्रेट फ़ोटो या MySQL में एक और कतार

समस्या का बयान

कार्यान्वयन

निष्कर्ष

More articles: