परियोजना के जीवन से एक वर्ष

इस लेख में मैं परियोजना के उत्तरों से जुड़े कार्यों के कार्यान्वयन में आने वाली सभी कठिनाइयों और नुकसानों को याद करने और उनका वर्णन करने का प्रयास करूंगा, मैं परियोजना की वास्तुकला के बारे में भी बताऊंगा।

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

15 अक्टूबर 2012 तक, इस परियोजना को प्रति दिन औसतन 3.5 मिलियन अद्वितीय आगंतुकों ने देखा।

गणना अद्वितीय "कुकीज़" (कुकीज़) द्वारा की गई थी, जो प्रत्येक आगंतुक को जारी की जाती हैं। यदि विज़िटर के ब्राउज़र में कुकीज़ का रिसेप्शन अक्षम है, तो विज़िटर की गणना नहीं की जाती है।

परियोजना के विजिटिंग कार्ड को स्क्रीन कहा जा सकता है, जो मुझे यकीन है कि हर कोई बहुत परिचित है



उपयोग की जाने वाली तकनीकों का सेट निम्नानुसार था:

• सेंटोस 5 i386
• mod_perl अपाचे के नीचे
• nginx
• SQL डेटाबेस
• rsync का उपयोग करके लड़ाई में कोड का लेआउट

वास्तुकला:

पहला नाम	भाग्य	cpu	राम, जी.बी.	HDD	एक नोट
सब से बड़ा	सामने	2xE5504	8	2 एक्स sata	प्रवेश बिंदु, बैलेंसर
अल्फा	इशारा	2xXeon पुराना	2	2 एक्स एससीआई	इस पर हम सभी क्राउन स्क्रिप्ट लॉन्च करते हैं
आर्गन	इशारा	2xE5504	8	2 एक्स sata
butan	इशारा	2x E5506	4	2 एक्स sata
luna	इशारा	2xE5405	8	2 एक्स sata	यहाँ वैप और मी संस्करण
OKTAN	इशारा	2xE5405	8	2 एक्स sata
metan	इशारा	2xE5506	4	2 एक्स sata
प्रोपेन	इशारा	2xE5405	4	2 एक्स sata
राडोण	इशारा	2xE5504	8	2 एक्स sata
नीयन	इशारा	2xE5-2620	16	2 एक्स sata	नई
नाइट्रोजन	इशारा	2xE5-2620	16	2 एक्स sata	नई
प्लाज्मा	इशारा	2xE5-2620	16	2 एक्स sata	नई
टाइटन	आधार	2 एक्स ई 5620	96	4sata + 20sas	गुरु
Buran	आधार	2 एक्स ई 5620	64	2 sata + 4 sdd	प्राथमिक प्रतिकृति
मैक्सिमस	आधार	2 x 5110	32	2 sata + 4 scsi	व्यवस्थापक पैनल के लिए प्रतिकृति
कनिष्ठा	आधार	2 x 5110	16	2 sata + 4 scsi	व्यवस्थापक पैनल के लिए प्रतिकृति
coloss	आधार	2 x 5130	8	6 स्कसी	टिप्पणी का आधार

समस्याएं हैं:

• परियोजना अस्थिरता
• इस SQL ​​डेटाबेस के लिए ऑपरेशन विभाग में कुछ विशेषज्ञ हैं, जब डेटाबेस गिरता है, तो एकमात्र विशेषज्ञ जो समझ सकता है कि क्या और क्यों हमेशा उपलब्ध नहीं है
• लैगिंग प्रतिकृतियों की शाश्वत समस्या, इसे हल करने वाला कोई नहीं है
• डेटाबेस के अंदर 90% तर्क के बाद से नई कार्यक्षमता का विकास मुश्किल है

नेतृत्व से चुनौती

सेवा के स्थिर संचालन और इसके आगे के विकास की संभावना सुनिश्चित करें, विशेष रूप से, मोबाइल संस्करण लॉन्च करें।

मैसिकल की ओर पलायन और एक तर्क में प्रक्रिया तर्क रखने से हमारी अधिकांश समस्याएं हल हो जाएंगी।

पहला चरण निगरानी कर रहा था। मैंने एक लेख में उनके बारे में लिखा (वैसे,
AnyEvent पर इसे फिर से लिखा गया, उत्पादकता 50 से 240 हजार लाइनों प्रति सेकंड तक बढ़ गई)।

उन्होंने निम्नलिखित बातों के लिए अपनी आँखें खोलीं:

1. हम हर दिन गिर जाते हैं!
2. त्रुटियों की एक विशाल पृष्ठभूमि 504, एक दिन में लगभग 50 हजार।

504 के कारण क्या हैं?

• एक धीमी गति से HTML पार्सर, यह प्रश्न पृष्ठ को प्रदर्शित करते समय, अर्थात् मक्खी पर अपना काम करता है।
• सामग्री को डाउनलोड करने वाले बॉट।
• Yandex और Google सूचकांक।

यैंडेक्स से एक पत्र आया:

Otvet.mail.ru के लिए, हमने लोड बढ़ाना शुरू किया, लेकिन प्रति मिनट 200 से अधिक अनुरोध करने के लिए नहीं किया
यह पता चला है, क्योंकि हम दिन के समय की परवाह किए बिना HTTP 503 प्राप्त करना शुरू करते हैं। क्या यह संभव है
इसे अपनी तरफ से खत्म करें?

एक और समस्या सामने आई: बैलेंसर पर हमारे पास एक आईपी से प्रति सेकंड 1 अनुरोध की सीमा है, अगर हम इसे बढ़ाते हैं, तो हम लोड का सामना नहीं कर सकते।

चूंकि रेस्पोंस प्रोजेक्ट के लिए खोज ट्रैफ़िक सबसे महत्वपूर्ण चीज़ है, इसलिए आपको जल्दी से कार्य करने की आवश्यकता है। हर कोई घबरा रहा है, स्थिति गर्म हो रही है =)।

सबसे सरल, सबसे आसान और सबसे सस्ता से - हमने 3 बैकएंड खरीदे: नियॉन, प्लाज्मा और नाइट्रोजन। उन्होंने प्राइमस बैलेंसर में रैम जोड़ा), सभी अनधिकृत उपयोगकर्ताओं के लिए nginx में html कैशिंग शामिल था, जो लगभग 40% हैं। बैलेंसर पर सीमा को बढ़ाकर प्रति सेकंड 15 अनुरोध किया गया था।

उन्होंने हर दिन गिरना बंद कर दिया, यांडेक्स ने अब हमारे बारे में शिकायत नहीं की। गंभीर समस्याएं हल हो गई हैं, अब आप कार्य के बारे में सोच सकते हैं।

आगे देखते हुए, मैं कहता हूँ कि नए एपीआई में, धीमी गति से HTML के साथ समस्याओं का समाधान किया गया है। हमने एक मालिकाना पार्स (पर्ल एक्सएल) पार्सर लागू किया और डेटाबेस को सहेजते समय ही पार्स किया। ऐसा समाधान मेल के लिए उपयुक्त नहीं है, क्योंकि यदि कोई व्यक्ति XSS पाता है, तो सभी पत्रों को पार्स करने में बहुत समय (5 पेटाबाइट डेटा) लगता है, इसलिए यह फ्लाई पर सुरक्षा और पार्स जोड़ने के लिए आसान और तेज़ है।

प्रवासन और मोबाइल संस्करण

माइग्रेशन को दो शर्तों को पूरा करना चाहिए: डेटा अखंडता बनाए रखना और 24/7 प्रदर्शन करना। इसलिए, परियोजना को बंद करना और डेटा स्थानांतरित करना विफल हो जाएगा।

हम एक एपीआई बनाएंगे, जिसके आधार पर सब कुछ काम करेगा, मोबाइल संस्करण और भविष्य दोनों "बड़ा"। एपीआई केवल पेशी से पढ़ेगा, और दोनों डेटाबेसों में लिखेगा: पुराना और नया।

MySQL के लिए पुराने डेटाबेस से परिवर्तन प्राप्त करने के लिए, आइए एक कतार शुरू करते हैं जिसमें हम लिखेंगे कि किन संस्थाओं को सिंक्रोनाइज़ करना है (पुराने से लें और नए में जोड़ें या बदलें)।

ऐसा करने के लिए, पूरे आधार को संस्थाओं में विभाजित किया जाना चाहिए। उदाहरण के लिए, उत्तर, प्रश्न, उपयोगकर्ता, सभी उपयोगकर्ता के उत्तर, आदि को फिर से सिंक्रनाइज़ करने का कार्य।

आपको यह भी विचार करने की आवश्यकता है कि इस कतार के हैंडलर समानांतर में काम करेंगे, क्योंकि सिंक्रनाइज़ेशन के लिए कार्यों की धारा बहुत बड़ी है। हम अंततः 12 कांटे को संसाधित करने में कामयाब रहे।

यह सब आवश्यक है ताकि किसी भी समय आप कतार में कार्य जोड़ सकें और आवश्यक संस्थाओं को पूरी तरह से फिर से सिंक्रनाइज़ कर सकें।

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

इस समय, मुख्य बात यह नहीं है कि निम्नलिखित चीजों के बारे में भूल जाएं:

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

उपरोक्त त्रुटियों में से प्रत्येक की लागत 14 दिन है। इतने सारे क्यों? इसके बारे में आप बाद में जानेंगे।

तो, पुराने संस्करण कतार में लिख सकते हैं, लोड की जांच कर सकते हैं। हम पुराने संस्करण को पहले 2 बीक पर रोल करते हैं, फिर 4 और पर, हम मांसपेशी को देखते हैं, सब कुछ ठीक है, हमने सभी बीक्स पर रोल किया, यह भार रखता है। अगले चरण पर जाएं।

उन्होंने एक क्यू हैंडलर लिखा जो जानता है कि कैसे कांटा और चिल्ड का ट्रैक रखना है: यदि वे गिरते हैं, तो यह नए पैदा करता है। वह कार्यों का एक हिस्सा लेता है और उन्हें फिर से सिंक्रोनाइज़ करता है, उन्हें हमारी जरूरत के ढांचे में बदल देता है। भविष्य में, हमने देखा कि दो रणनीतियों - 12 कांटे लॉन्च करना, जिनमें से प्रत्येक में सभी प्रकार के कार्यों को रेक करना - 4 फोर्क लॉन्च करने की तुलना में धीमी है, जो कि कार्य A, 4 कांटे जो कि पूर्ण कार्य B, आदि करते हैं।

यह इस तथ्य से समझाया गया है कि कतार प्रोसेसर उन इकाइयों को याद करता है जो इसे वर्तमान पास के लिए पुन: सिंक्रनाइज़ करते हैं, और अगर यह फिर से मिलता है, तो उन्हें छोड़ देता है, और जब संस्थाओं के प्रकार को प्रतिबंधित करते हैं, तो पहले से ही संसाधित कार्य में आने की संभावना बहुत अधिक है।

नतीजतन, हमने कतार में लिखने के लिए पुराने संस्करण को पढ़ाया, कतार प्रोसेसर तैयार हैं। पुराने संस्करण को युद्ध में लॉन्च किया गया है। कतार खड़ी हो रही है, लेकिन अभी तक उखड़ा नहीं है।

अब हमें पहले से संचित डेटा को एक डेटाबेस से दूसरे में स्थानांतरित करना होगा। वे लगभग 500 गीगाबाइट हैं। यह कैसे करना है? धन्यवाद एलेक्स क्यू =)

उद्देश्य:

पुराने SQL डेटाबेस से MySQL में बड़ी तालिकाओं (1500 मिलियन रिकॉर्ड तक) का माइग्रेशन। उसी समय, संरचना (थोड़ा) बदल सकती है, उदाहरण के लिए, पुराने SQL डेटाबेस में, बूलियन फ़ील्ड CHAR (1) (छिपे हुए मान 'या' H ') हो सकते हैं, और MySQL में वे TINYINT हो जाएंगे (छिपा हुआ 0 या 1 हो सकता है)।

डेटा ट्रांसफर के साथ, डेटा को पुराने डेटाबेस में जोड़ा और संशोधित किया जा सकता है। समस्या को एक कतार बनाकर हल किया जाता है जिसमें पुराने डेटाबेस में कौन सा डेटा बदल गया है या जोड़ा गया है, इसके बारे में जानकारी लिखी जाती है। जबकि तालिका पलायन कर रही है, कतार में "पूर्व-तुल्यकालन" के लिए नौकरियां जमा हो रही हैं; कतार को एक अलग स्क्रिप्ट में पार्स किया जाता है।

स्थानांतरण के बाद:

1. 1000 के पैक में (डिफ़ॉल्ट रूप से, स्टार्टअप कुंजियों द्वारा ओवरराइड), पैक में MySQL के माध्यम से MySQL में आयात करें, क्योंकि यह INSERT के माध्यम से बहुत तेज है।
2. डेटा ट्रांसफर फ़ाइल के रूप में FIFO पाइप का उपयोग करें, क्योंकि तब सभी डेटा डिस्क से लिखे बिना मेमोरी के माध्यम से चलाया जाता है। यह फ़ाइलों की तुलना में काफी तेज होना चाहिए।
3. स्क्रिप्ट पुराने SQL डेटाबेस (उदाहरण के लिए 10000) से एन लाइनें पढ़ती है।
4. स्क्रिप्ट बाल प्रक्रिया को पार्स करती है। इस प्रक्रिया में, पढ़ने के लिए एक FIFO खोला जाता है, और इसमें से MySQL LOAD DATA INFILE करता है।
5. माता-पिता पंद्रह में K लाइनें (उदाहरण के लिए 1000) लिखते हैं। प्रत्येक पैक के बाद, यह पाइप के फ़ाइल हैंडल को बंद कर देता है, बच्चे की प्रक्रिया से बाहर निकलने की प्रतीक्षा करता है, और चरण 2 से दोहराता है जब तक कि चरण 1 में लिया गया डेटा बाहर नहीं निकल जाता है।

26 फरवरी, 2013 - पहली प्रतिबद्ध। 6 मार्च, 2013 तक एक कार्यशील संस्करण तैयार है। हमने एक फ़ंक्शन बनाया जो आने वाली तालिका (पुराने SQL डेटाबेस) और आउटपुट तालिका (MySQL) old_to_MySQL () का विवरण लेता है, और फिर इसके माध्यम से सब कुछ किया जाता है। अचानक फैकैप के दौरान खरोंच से शुरू न करने के लिए, हम पुराने माइग्रेट पंक्ति की आईडी को पुराने_मिग्रेट MySQL टेबल में प्रत्येक तालिका के लिए संग्रहीत करते हैं।

हम LOAD INFILE REPLACE का उपयोग करते हैं, और LOAD INFILE IGNORE का उपयोग नहीं करते हैं, ताकि जब एक फेकाप से रिकवर किया जाए, तो आप पुराने SQL डेटाबेस में डेटा परिवर्तन नहीं खोएंगे।

15 मार्च को, डिफ़ॉल्ट मानों के साथ समस्या अस्थायी रूप से हल हो गई थी: यदि NULL पुराने SQL डेटाबेस से आता है, और MySQL में NOT NULL DEFAULT कॉलम 0 है, तो हम NULL सम्मिलित करने का प्रयास करते हैं। योजना के विवरण में अब प्रमुख स्तंभों का एक सेट है, जो शेष सभी में होना चाहिए, यदि NULL आता है तो हम DEFAULT सम्मिलित करते हैं।

20 मार्च को, SIGPIPE के खिलाफ युद्ध शुरू हुआ।

युद्ध के चरण:

• $ SIG {PIPE} को जोड़ा गया, जो सहेजे गए स्थान से पुराने मापदंडों के साथ पुराने_to_MySQL () को कॉल दोहराने की कोशिश करता है। लंबे समय तक, सब कुछ काम किया।
• नवंबर 13-14 SIGPIPE वापस आ गया। मैंने पाइप के साथ काम करने की प्रक्रिया तय की: पहला, पढ़ने के लिए पंद्रह को खोलें, फिर लिखने के लिए। सिगाइप के खिलाफ लड़ाई के दौरान, हमने क्रैक / कार्प को डाई / चेतावनी के प्रतिस्थापन के रूप में जोड़ा और कारप में बग 72467 पर ठोकर खाई (मुक्त स्केलर को कॉपी करने का प्रयास), और सब कुछ वापस बदल दिया।
• इसने मदद नहीं की पढ़ने के लिए पाइप खोलने के बाद नींद ने एक सेकंड में मदद नहीं की। हम अस्थायी फ़ाइलों पर चढ़ गए। यह पूरी तरह से नींद पूरी न होने के कारण और अधिक तेज हो गया, जो सिगाइप के खिलाफ लड़ाई में बैसाखी के रूप में कार्य करता था। यह अच्छा हो गया।

13 और 14 नवंबर को सिगिपिप युद्ध दो दिनों तक चला था। दो दिन बहुत व्यस्त रहा।

कुल मिलाकर, इन 500 गीगाबाइट को स्थानांतरित करने में हमें 14 दिन लगे।

जबकि स्थानांतरण प्रगति पर था, नए API (पर्ल, fast_cgi) का अल्फा संस्करण पहले से तैयार था।

स्थानांतरित डेटा, कॉर्पोरेट उपयोगकर्ताओं के लिए एक परीक्षण मोबाइल संस्करण लॉन्च किया। हम देखते हैं, हम परीक्षण करते हैं। संयोग से, पुराने संस्करण के लॉग में, उन्होंने एक त्रुटि देखी कि किसी एक पर, डीबीडी मॉड्यूल की अनुपस्थिति में थोड़ा पेरोज़्चका कसम खाता है। इसका मतलब है कि सामने से नौकरियां कतार से बाहर नहीं निकल रही हैं और कुर्सियां ​​लगातार नहीं हैं। ओह, बकवास। मुझे फिर से सब कुछ ट्रांसफर करना पड़ा। 14 दिन बीत गए =)।

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

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

यह काम करने लगता है। आगे बढ़ो।

नया API दोनों डेटाबेस में लिखने में सक्षम होना चाहिए। हम अतुल्यकालिक रूप से लिखते हैं ताकि ज्यादा समय इंतजार न करना पड़े। ऐसा करने के लिए, नए डेटाबेस की तालिकाओं में, हम ऑटो-वेतन वृद्धि की प्रारंभिक स्थिति का उपयोग करके आईडी द्वारा एक रिजर्व बनाते हैं। उदाहरण के लिए, पुराने डेटाबेस में प्रश्न की अधिकतम आईडी 1000 है, तो नए डेटाबेस की समान तालिका में हमने ऑटो-इंक्रीमेंट 2000 की प्रारंभिक स्थिति निर्धारित की है।

हम नए एपीआई के माध्यम से प्रश्न जोड़ते हैं, यह 2001 के पहचानकर्ता को बदल देता है, हम इसे पुराने डेटाबेस में जोड़ते हैं, इसमें पहचानकर्ता 1001 है, हम पहचानकर्ता 2001 के साथ रिकॉर्ड को अपडेट करते हैं, हम इसे पहचानकर्ता 1001 के साथ रिकॉर्ड में बदल देते हैं, इसलिए संस्थाओं के लिए पहचानकर्ता हमारे डेटाबेस में मेल करेंगे। ।

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

आवश्यक संस्थाओं को फिर से सिंक्रनाइज़ करने के लिए कतार के कार्यों को जोड़कर सभी आगे के फेकैप्स को हल किया गया था।

मुझे एक और बात याद आई: किसी तरह, ऑपरेशन विभाग से, हमने समाचार सुना कि आपको डेटा केंद्रों में से एक का भुगतान करना पड़ सकता है, और यह देखते हुए कि मोबाइल संस्करण पहले से ही युद्ध में है और पुराने डेटाबेस वाले सर्वर इस डेटा केंद्र में हैं, और नए MySQL डेटाबेस दूसरे में - यह पूरी तरह से उदास हो गया। लेकिन, सौभाग्य से, पूर्वानुमान भौतिक नहीं थे।

सोचिए क्या हुआ।

हमने पुराने डेटाबेस के साथ डेटा सेंटर को चुकाया - फिर हम जल्दी से किसी अन्य डेटा सेंटर में सामने को कर्ल कर देते हैं (हमने इस खबर के बारे में पता चलने पर इसे तुरंत किया), मोबाइल संस्करण को केवल-पढ़ने के लिए मोड पर स्विच करें और सभी को मोबाइल संस्करण पर रीडायरेक्ट करें।

हमने नए डेटाबेस के साथ डेटा सेंटर को चुकाया - हम सिंक्रनाइज़ेशन के लिए कतार में रिकॉर्डिंग बंद कर देते हैं। डेटा केंद्र काम करना शुरू करने के बाद, हम समस्याओं की शुरुआत के बाद बनाई गई सभी संस्थाओं को कतार में फेंक देते हैं और चुपचाप पुन: सिंक्रनाइज़ करते हैं।

मार्च में, मोबाइल संस्करण लॉन्च किया गया था। एक दिन में लगभग 500 हजार अनोखे लोग वहां आए। हम लोड पकड़ते हैं, सब कुछ स्मार्ट तरीके से काम करता है।

परियोजना की वास्तुकला ने निम्नलिखित रूप लिया:

पहला नाम	भाग्य	cpu	राम, जी.बी.	HDD	एक नोट
बरोन	सामने	2xE5-2620	32	2 एक्स sata	httpd + mod_fcgid, बड़ा पावर मार्जिन
बर्बन	सामने	2xE5-2620	32	2 एक्स sata	httpd + mod_fcgid, बड़ा पावर मार्जिन
Bereza	आधार	2xE5-2609	96	2 x sata + 10 x ssd	mysql मास्टर
sosna	आधार	2xE5-2609	96	2 x sata + 10 x ssd	mysql प्रतिकृति
pihta	आधार	2xE5-2609	96	2 x sata + 10 x ssd	mysql प्रतिकृति
vagon	memkesh	2xE5-2620	64	2 एक्स sata	दो संस्मरण उदाहरण

हमने खोज इंजन और जेएस अक्षम लोगों के लिए एक सर्वर संस्करण बनाना शुरू किया।

उन्होंने इसे किया, इसे मॉस्को क्षेत्र में लुढ़काया। हमने देखा कि प्रति सेकंड 800 अनुरोधों के भार के साथ, अपाचे जल रहा है। सबसे पहले, संदेह mod_fcgid पर गिर गया, लेकिन यह पता चला कि अपराधी mod_rpaf था। मॉन्स की बदौलत, उन्होंने निपुणता से अपाचे क्रस्ट खेला।

उन्होंने mod_rpaf को त्याग दिया, एक्स-रियल-आईपी हेडर के माध्यम से नग्नेक्स का उपयोग करके आईपी को फेंक दिया।

उन्होंने इसे पूरे रूस में घुमाया, हम लोड को बनाए रखते हैं। उन्होंने एक नया "बड़ा" संस्करण बनाया, जिसने सभी को पुनर्निर्देशित करना शुरू कर दिया। 19 नवंबर को, पुराने संस्करण को बंद कर दिया गया था।

प्राइमस बैलेंसर पर नरक प्रतिबंध को हटा दिया (एक आईपी से प्रति सेकंड 15 अनुरोध)। हम लोड को सामान्य रखते हैं। एपीआई से प्रति सेकंड लगभग 950 अनुरोध।

उपस्थिति प्रति दिन औसतन 6.5 मिलियन है।

हम सभी सर्वरों पर सेंटोस 64 बिट का उपयोग करते हैं, आरपीएम पैकेज के माध्यम से रोलआउट टू बैटल होता है। फिलहाल, अप्लाका अभी भी Apache2 (mod_fcgid) के तहत घूम रहा है। यम ने बैग को रोल करने के बाद, हम बदले में बीक्स को पुनः आरंभ करते हैं।

मोर्चे पर, हम इस चीज़ का उपयोग करते हैं:
proxy_next_upstream timeout error http_502 http_504;

यही है, अगर उपयोगकर्ता 502 या 504 प्राप्त करता है, तो उसे दूसरे बैक-एंड की अनुमति दी जाएगी, इस प्रकार अपाचे को पुनरारंभ करने के कारण असुविधा को कम करना होगा।

लोड चार्ट यहां देखे जा सकते हैं ।

मुझे उम्मीद है कि यह नोट आपको उस रेक पर कदम नहीं बढ़ाने में मदद करेगा, जिस पर हम चले थे! याद रखें, दूसरों की गलतियों से सीखना बेहतर है अपने से! :)