अत्यधिक लोड एप्लीकेशन आर्किटेक्चर। स्केलिंग वितरित प्रणाली। भाग दो

इस हफ्ते हमने डिक्रिप्टेड पॉडकास्ट के पहले भाग को रखा। अब उन्होंने दूसरा भाग तैयार किया है।

हम पॉडकास्ट के दूसरे भाग में क्या बात करते हैं:

• स्केल प्रोजेक्ट क्षैतिज रूप से

- कब क्लाउड सेवाओं का उपयोग करें, और जब भौतिक होस्टिंग;
- "सुंदर समाधान" बनाम "गंदा लेकिन उत्पादक" कोड। ORM और सभी प्रकार की समान चीजें;
- बहु-भाषा और बहु-क्षेत्र परियोजना, समस्याएं और समाधान।

• अतुल्यकालिक कार्य। कतार।

- वितरित प्रणालियों में अतुल्यकालिक कार्य;
- जब वे बचाव में आते हैं, तो क्या प्रौद्योगिकियां मौजूद हैं और अब सक्रिय रूप से विकसित हो रही हैं;
- एसिंक्रोनस कार्यों को आयोजित करने के लिए कौन से दृष्टिकोणों का उपयोग बेत में किया जाता है;
- कतारों के साथ काम करने पर आपको क्या समस्याएं थीं और सामना करना पड़ा;
- उपयोगी किताबें और दिलचस्प सम्मेलन;
- दिलचस्प साक्षात्कार के मामले।


वेद: हाँ, यह एक अच्छा तरीका है, क्योंकि इंजीनियर ... वे अक्सर ऐसे पूर्णतावादी होते हैं, वे पूरी तरह से करना चाहते हैं और साथ ही साथ यह भी बर्दाश्त कर सकते हैं - अगर उन्हें नियंत्रित नहीं किया जाता है - दस बार फिर से तैयार करना। मैं क्या कह सकता हूं - मैं खुद को याद करता हूं, सामान्य तौर पर, ऐसा था। और समय के साथ, यह समझना कि कभी-कभी तेजी से करने की आवश्यकता होती है अनुभवी तकनीशियनों, इंजीनियरों को आता है। मुख्य बात यह है कि एक परिणाम होना चाहिए, न कि यह "वैक्यूम में गोलाकार लक्ष्य"।

सिद्धांत रूप में, आपके पास एक बहुत ही सही, उचित दृष्टिकोण है। और सामान्य तौर पर, मैंने "हैबे" के लेखों को देखा जो आपने लिखा था कि आप "तैनाती" को कैसे स्वचालित करते हैं, गिट का उपयोग करके नए रिलीज के "रोलिंग आउट"। आप उपयोग कर रहे हैं, जहाँ तक मुझे पता है, JIRA बग ट्रैकर, टीमसिटी के रूप में। और यह सब एक साथ, आप किसी तरह वहां अच्छा महसूस करते हैं, एआईडीए जैसे उपकरण के साथ शानदार खाना बनाते हैं। मैं भविष्य में किसी भी तरह से, हमारे पॉडकास्ट के अगले मुद्दों में से एक में, इस बारे में और अधिक विस्तार से बात करने के लिए सुझाव दूंगा। अब हम शायद वहाँ रुकने वाले नहीं हैं। मुझे लगता है कि आपके पास बताने के लिए कुछ है, आपको टीम के भीतर इन सभी प्रक्रियाओं के अच्छे डिबगिंग का अनुभव है। और इस एक और बात के बारे में बात करते हैं: जैसा कि मैं इसे समझता हूं, आपके पास जो डेवलपर्स हैं, वह भी एक सवाल है, वैसे, रोमन स्कवाज़ से - वे "मल्टी-प्लेटफॉर्म" नहीं हैं, कि आप उन्हें स्पष्ट रूप से साझा करते हैं। PHP shniks हैं, syshniks हैं, और डेटाबेस के लिए यह बहुत ही अनुभवी और शक्तिशाली DBA है, है ना?

एआर: एक तरह से या किसी अन्य, किसी भी कंपनी में प्रवेश होना चाहिए। और अगर सैकड़ों डेटाबेस सर्वर हैं, तो डीबीए बस वहां होना चाहिए क्योंकि चीजों को ठीक करना और नए डेटाबेस का ट्रैक रखना डेवलपर का काम नहीं है। इसलिए मेरे पास हाल ही में एक छोटा बजट था और मैंने MySQL के लिए एक पैच का आदेश दिया, जिसे दस साल तक वे ठीक नहीं कर सके। और मुझे एक सिस्टम प्रशासक को शामिल करने की आवश्यकता थी, ताकि सभी समूहों पर यह सब अपडेट हो जाए। डीबीए होना चाहिए, इस पर भी चर्चा नहीं की गई है। ठीक है, और "मल्टी-प्लेटफॉर्म" ... आम तौर पर, जो लोग PHP जानते हैं, वे निश्चित रूप से कुछ अन्य स्क्रिप्टिंग भाषाओं को जानते हैं। उनमें से लगभग 100 हैं, ठीक है, शायद कम - लगभग 80 लोग। वे PHP और कुछ अन्य स्क्रिप्टिंग भाषाओं को जानते हैं, लेकिन वे ज्यादातर PHP में लिखते हैं। हमारे पास काफी कम sishers हैं, अर्थात्, और बड़े से, हम एक व्यक्ति को एक टीम से दूसरी टीम में स्थानांतरित कर सकते हैं।

सामान्य रूप से प्लेटफार्मों के लिए ... संभवतः, हमारे डेवलपर्स में कोई भी ऐसा नहीं है जो वेब के नीचे और साथ ही साथ एंड्रॉइड के तहत लिख सकता है। क्योंकि एंड्रॉइड के तहत हम लिखते हैं कि ... हमारे पास जावा है, मेरी राय में, हां। और आईओएस के तहत हमारे पास ऑब्जेक्टिव-सी है। यही है, हमारे पास ऐसा "मोबाइल चिड़ियाघर" है, और इस अर्थ में, जो लोग मोबाइल एप्लिकेशन के लिए सर्वर साइड लिखते हैं और मोबाइल एप्लिकेशन के लिए क्लाइंट साइड लिखने वाले लोग वास्तव में अलग लोग हैं।

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

एआर: यह मुझे लगता है कि समस्या एक जटिलता की औसत प्रकृति के बजाय है, अर्थात्, एक बड़ी परियोजना में प्रदर्शन की तुलना में और स्केलिंग के साथ, यह, ज़ाहिर है, इतनी बड़ी समस्या नहीं है। "मल्टी-ज़ोन" के रूप में, वहां, मेरी राय में, सब कुछ सरल है, और यह कॉन्फ़िगरेशन द्वारा तय किया गया है। एक छोटी फ़ाइल है: देश और, मोटे तौर पर, UTC में समय बदलाव - और UTC में एक ही प्रारूप में सब कुछ संग्रहीत करना और गणना करना। यह बहुत आसान है।

बड़ी संख्या में ग्रंथों के लिए, यह वास्तव में एक दिलचस्प सवाल है। हम कई अलग-अलग चरणों से गुजरे और इस तथ्य के साथ समाप्त हुए कि अब हमारे पास एक ऐसा अनुवाद होगा जहां उपयोगकर्ता स्वयं अनुवाद करेंगे। हमारी कई दर्जन भाषाएं हैं। मुझे ठीक से याद नहीं है ... लगभग 40. और, ज़ाहिर है, हमारे लिए यह बहुत महत्वपूर्ण है कि अनुवाद प्रणाली पर्याप्त रूप से मोबाइल हो ताकि सुविधाएँ धीमी न हों।



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

और हम फीचर को रोल आउट नहीं कर सकते हैं। इसके बजाय - हम केवल कुछ देशों के लिए एक सुविधा को रोल कर सकते हैं, इसे चला सकते हैं, लेकिन हम इन अनुवादों के बिना पूरी तरह से रिलीज़ नहीं कर सकते। अब कल्पना करें, यहां हमारे पास एक रिलीज चक्र है - ये प्रति दिन दो रिलीज हैं। हम एक दिन में दो रिलीज करने के लिए सब कुछ कर रहे हैं। ऐसा करने के लिए, हमें जल्दी और इतने पर पारित करने के लिए दस मिनट में हमारे 15 या 16 हजार परीक्षणों की आवश्यकता है (क्लैरिफिकेशन: 3.5 मिनट में पहले से ही 18 हजार) । हम, यदि हम इस रिलीज को करते हैं, तो हम अनुवाद के लिए इंतजार नहीं करना चाहते हैं। इसलिए, जब हमने एक नई तैनाती प्रणाली बनाई, तो हमने अनुवाद प्रणाली को बहुत बदल दिया, तथाकथित को एकीकृत करते हुए, मैं यह भी नहीं जानता कि इसे सही कैसे कहा जाए ... ऐसा "आगे स्थानांतरण"। यानी मोटे तौर पर, यहां तक ​​कि परीक्षण के चरण में, "मंचन" पर, जो आमतौर पर एक दिन में या कुछ दिनों में होता है, अनुवादक पहले से ही सुविधा का अनुवाद करना शुरू कर सकता है, जो तब परीक्षण चरण में, उत्पादन पर जाएगा। और चूंकि कई दसियों अनुवादक हैं, मुख्य "चुनौती" अनुवाद के लिए एक सुंदर और समझने योग्य इंटरफ़ेस बनाना था। विशेष रूप से, हमने स्क्रीन अनुवाद जैसे प्रारूपों के साथ प्रयोग किया। एक विशेष अनुवाद सत्र है: आप अंदर जाते हैं, अंग्रेजी में साइट देखते हैं और रूसी में अनुवाद करते हैं; आप अंग्रेजी में कुछ पाठ देखते हैं, क्लिक करें, रूसी में अनुवाद करें, क्लिक करें और तुरंत रूसी में सब कुछ देखें। हां, ठीक है।

वेद: हाँ।

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

वेद।: मानक, वहाँ कुछ प्रकार की कवि-फाइलें हैं, अर्थात्, जैसा कि मैं इसे समझता हूं, सब कुछ छोटी परियोजनाओं के लिए किया जा सकता है, इसे आज़माएं, है ना?

AR: मैं यहां यह नहीं कहूंगा कि यह सब निश्चित रूप से एक बड़े, बड़े प्रोजेक्ट को धीमा करना शुरू कर देगा, लेकिन यह स्पष्ट है कि यदि आपके पास किसी भाषा में तैयार किए गए टेम्पलेट हैं, तो आप बस समय बर्बाद नहीं करते हैं, आमतौर पर नहीं एक विशेष वाक्यांश के लिए खोज करने के लिए CPU समय। यदि पृष्ठ स्वस्थ है - हाँ, यह स्पष्ट है कि ये वाक्यांश "डॉफ़ीगा" होंगे, अर्थात्, ऐसी खोजें - भले ही यह एक त्वरित खोज होगी, लेकिन आपको अभी भी कुछ समय प्रोसेसर की राशि खर्च करने की आवश्यकता है।

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

एआर: इस तरह की बारीकियां हैं: हम, सिद्धांत रूप में, कम बार तैनात कर सकते हैं, लेकिन यह पता चला है कि निरीक्षणों की लय, कुछ प्रयोग, हमारे किराने के कार्यालय की लय ऐसी है कि दिन में एक बार पर्याप्त नहीं है। उन्होंने दिन में दो बार फैसला किया, और क्यों नहीं - क्योंकि अधिक रिलीज, रिलीज के समय अक्सर कुछ लोगों के काम को लकवा मार जाता है। कम से कम इंजीनियरों को रिहा करो। हमारे पास रिलीज़ इंजीनियरों का एक समूह है - हमने इसे इकट्ठा किया है, वैसे, अभी हाल ही में।

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


वेद: हाँ। लेकिन, मेरी राय में, यह और भी शांत है, अर्थात, मैं वास्तव में नहीं जानता कि आप एक दिन में कितनी सुविधाएँ जमा कर सकते हैं, ताकि शाम को लुढ़का जा सके।

वेद: लेकिन वे, जैसा कि मैं इसे समझता हूं, पहले से पता है। मुझे नहीं पता कि आपने इसे कैसे बनाया है - स्क्रम या कुछ और। आपके पास, कार्यों का एक निश्चित समूह है। और आप समझते हैं कि कहते हैं, कल के एक दिन बाद तक वे पूरे हो जाएंगे और सुबह आप उन्हें रोल आउट कर सकते हैं। और इसलिए यह हर समय होता है, है ना?

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

वेद: क्या आपका विकास कार्यालय एक स्थान पर स्थित है या कुछ टीमों को भौगोलिक रूप से वितरित किया गया है?

एआर: हमारे पास मॉस्को में अधिकांश सर्वर विकास है, सर्वर विकास का हिस्सा - एक छोटा सा हिस्सा - लंदन में है, और, बदले में, मॉस्को में व्यावहारिक रूप से कोई मोबाइल विकास नहीं है - लंदन में सभी मोबाइल विकास। यहाँ एक अलगाव है।

वेद: संचार के साथ एक और सवाल, निश्चित रूप से, उठता है। और अंत में, इस बारे में बात करें कि आप ORM की तरह क्यों नहीं हैं।

AR: मैं निम्न कारणों से ORM को पसंद नहीं करता : मैं ORM से बीमार हुआ करता था, और मैंने खुद ORM किया था, और मुझे ऐसा लगा कि यह एक महान "सिल्वर बुलेट" है। और मुझे एहसास हुआ कि इस समस्या को - यह निम्नलिखित कारणों से सामान्य तरीके से हल नहीं किया जा सकता है। कारण संख्या एक यह है कि डेटाबेस और ऑब्जेक्ट विकास के बीच एक मौलिक, तथाकथित प्रतिबाधा बेमेल है। और अगर हम कुछ ऐसा करते हैं जो डेटाबेस के साथ अच्छी तरह से काम नहीं करता है, तो इससे भी बुरा है कि अगर हम ऐसा कुछ करते हैं जो बहुत अच्छी तरह से ऑब्जेक्ट ओरिएंटेड नहीं है या बहुत सुंदर नहीं है, क्योंकि सभी "जाम" सबसे अधिक संभावना है हम डेटाबेस में आउटसोर्स करेंगे - यह परियोजना के लिए अधिक जोखिम भरा है। इसलिए, डेटाबेस को यथासंभव कुशलता से उपयोग किया जाना चाहिए। और आपको SQL में इसके साथ "बात" करने की आवश्यकता है। SQL भाषा में उससे बात करने के लिए, आपको इस SQL ​​को प्रभावित करने सहित सक्षम होना चाहिए। और अधिकांश ORM इसलिए लिखे गए हैं, कि सामान्य तौर पर, आपके लिए सब कुछ किया जाता है।

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

प्रश्न, वास्तव में, मनोविज्ञान में विशेष रूप से है: यह लोगों को लगता है कि इस परत को लिखने में समय बिताने का मतलब है, मोटे तौर पर बोलना, खुद का सम्मान नहीं करना। और अगर कुछ मेरे लिए मशीन द्वारा स्वचालित रूप से किया जा सकता है - तो मैं इसे क्यों करूंगा? वास्तव में, ऐसा नहीं है। एक बड़ी परियोजना में इस परत को लिखने के लिए इतना समय नहीं है, लेकिन तुरंत इस परत को खोलना, जो डेटाबेस से बात करता है और फिर डेटा को कहीं लौटता है, और फिर वे वस्तुओं में अलग-अलग हो जाते हैं ... हाँ, यह परत आपको डेटाबेस से बात करने की अनुमति देती है जिस भाषा में मुझे कुछ भी "ट्यून" करना है, उसे बदलना काफी आसान है, ठीक है, मानक ORM की तुलना में थोड़ा अधिक कोड है। इसके अलावा, यदि आप यह देखते हैं कि ORM मुख्य रूप से कहां उपयोग किया जाता है ... ORM छोटी परियोजनाएं हैं जहां आप जल्दी से एक इंटरफ़ेस बना सकते हैं, मुझे संपादन का पता नहीं है, लेकिन कुछ सरल इकाइयां हैं। विश्लेषण के साथ काम करने वाले कम से कम कुछ लिखने के लिए ORM का उपयोग करने का प्रयास करें। यही है, डेटा की एक निश्चित राशि है, और आपको विश्लेषणात्मक प्रश्न करने की आवश्यकता है ...

वेद: ठीक है, हाँ, यह मुश्किल है, यह मुश्किल है।

वेद: यहाँ यह है। और यहाँ मैं बस Mongo के लिए सभी प्रकार के newfangled ODM की तलाश में हूं। अब, और Doctrine'u समर्थन करते हैं, मंडंगो के सभी प्रकार हैं। सहकर्मियों के पास अनुभव है, कहने दो, न कि सबसे "छोटे पैमाने पर" परियोजनाओं पर जहां वे इसका उपयोग करते हैं। लेकिन यहाँ, उदाहरण के लिए, हम केवल कुछ परतों में भी लिखते हैं जो हमें कुछ कार्यों को स्वचालित करने में मदद करती हैं न कि अनुरोधों के किसी भी अनावश्यक समान टुकड़े को "कॉपी-पेस्ट" करने में। लेकिन इस स्तर पर सब कुछ अब परियोजना में हो रहा है, इसलिए हम इसका उपयोग नहीं करते हैं। मैं पॉडकास्ट के अंत में जाने और एक और बहुत ही रोचक और मूल विषय पर बात करने का प्रस्ताव करता हूं - यह है कि जब हम एक परियोजना विकसित कर रहे हैं, तो हम कुछ घटकों को अलग करने के लिए अधिक से अधिक प्रयास कर रहे हैं और इसके अलावा, हम समझते हैं कि हम कई और कार्य कर सकते हैं अतुल्यकालिक रूप से। और यहाँ इस तरह के शब्द कतार में आते हैं - ये सभी प्रकार के अतुल्यकालिक कार्य, async जॉब्स हैं। आप उनके साथ कैसे काम करते हैं, आप क्या करने आए हैं, आप क्या इस्तेमाल कर रहे हैं?

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

बस कल्पना करें कि आप एक उपयोगकर्ता हैं, डेटाबेस में कुछ नोड पर रहते हैं और कुछ फोटो भरते हैं या कुछ लिखते हैं और उदाहरण के लिए, संदेश में कुछ पते को फ्लैश करते हैं। यदि आप कोई फोटो अपलोड करते हैं, तो उसे मॉडरेट किया जाना चाहिए। यदि संदेश में कुछ पता चला है, तो शायद हम इस तथ्य के बाद इसे दोबारा जांचना चाहते हैं कि क्या आप एक स्पैमर हैं, और विभिन्न प्रणालियों से जानकारी एकत्र करते हैं, कुछ प्रकार की रेटिंग बनाते हैं, यदि इस लिंक का अक्सर वहां उल्लेख किया जाता है और इसी तरह। ऐसा कुछ, हाँ, विश्लेषण कैसे करें? शायद आपने अभी पंजीकृत किया है और मुझे नहीं पता, हमारे लिए कुछ तरह के ट्रिगर ने काम किया है - एक डबल-चेक। सामान्य तौर पर, किसी प्रकार की देरी से घटना को अंजाम देना पड़ता है। यह सब, इन सभी अतुल्यकालिक चीजों को डेटाबेस में लेनदेन द्वारा उत्पन्न किया गया था जिसमें आप "जीवित" हैं। इसलिए, कल्पना करें कि हमारे पास किसी प्रकार का तृतीय-पक्ष सर्वर है जो कतारों को संसाधित करता है। दो-चरण प्रतिबद्ध और संचालन के सिंक्रनाइज़ेशन की समस्या है। तो यह स्पष्ट है कि समस्या क्या है एक दो-चरण की प्रतिबद्धता मूल रूप से एक मिथक है, और किसी तरह हम असंगत डेटा प्राप्त कर सकते हैं। यही है, या तो डेटाबेस में सब कुछ ठीक हो जाएगा, लेकिन हमें घटना की अनुपस्थिति मिलेगी, किन कारणों से यह खो जाएगा; या डेटाबेस में सब कुछ खराब है - अर्थात, लेन-देन नहीं हुआ, और किन कारणों से शुरू नहीं किया गया था, लेकिन यह घटना प्रतीत होती है।

वेद: हाँ।

AR: तो कुछ बिंदु पर हमने इस तरह की समस्याओं को हल नहीं करने का फैसला किया। चूँकि हमारे पास अभी भी डेटाबेस द्वारा ईवेंट जनरेट किया गया है, तो इसे उसी डेटाबेस पर बनाया जाए जहाँ यह ईवेंट उसी लेन-देन में उत्पन्न किया जा सकता है। और एक अलग प्रणाली है, जो तब इस घटना को केंद्र में इकट्ठा करती है या इसे विकेंद्रीकृत तरीके से संसाधित करती है। मैं इस योजना के बारे में संगोष्ठी में अधिक विस्तार से बात करता हूं।

विचार यह है कि ऐसी घटनाओं की कुल संख्या बहुत बड़ी नहीं है। प्रति सर्वर पर आपके कितने लेनदेन हैं? मान लीजिए कि प्रति सेकंड कई सौ हैं - उसी लेनदेन में आप इस घटना के बारे में एक काफी कॉम्पैक्ट रिकॉर्ड बना रहे हैं। यह वार्तालाप इस तथ्य के बारे में नहीं है कि हम एक क्लिक या कुछ और से संबंधित कुछ अरबों घटनाओं को पंप कर रहे हैं। नहीं, यह वह सब है जो एक डेटाबेस में लेनदेन को जन्म देता है।

, ( , , , , , ). - , Facebook – Scribe, -, , . - , - . , , Scribe.

- , -, RabbitMQ, 0MQ. - , , , , , , Scribe. , , , , Pinba — , UDP- application- «» , . , - .

.: , , MySQL, , MySQL? — , ?

..: , .

.: , , , , .

..: , - , .

.: , . … … , , , , , . तो क्या? , - . , - .

..: , , . , , , , . - , . - - — , . — , . . - , , .

, UDP, - ( UDP ) - , . , , , . - , , . , , , , -, , , . .

.: , . - ?

..: .

.: , , , , , . , , - , , , real-time, , , - .

..: Badoo «». , «» , Badoo .

.: . , , ?

..: , , . , , , . . . . research, , , , , , - «» .

. , ? , , « ». - , « ». application-, web. «» «», , . .

.: , , , . , «», - . , , PHP, , , , , , «» , , «». , Facebook HipHop' HipHopVM . , ? - , ?

..: : , , , , , . , - , . , , PHP, : «, «» Ruby, Ruby», : « , , , , Ruby», , , -. , , , , .

, - , , . , -, , , , . - Python', , , « , , ». . , , , . - . , ( , ), , , «». , - . , , , . .

.: . , , . .

..: --. , .

.: , : , . , : , , , , - ?

..: , , . . : , «» . , . , . , , , .

, , - Erlang' — . — production-. Badoo , , , . , , . , , , : « , , , , -». , , , , . - , - , , , .

.: , , , - , , , - , . .

..: , , . , , , . , , , , , - , . , , - , , , .

.: , , . , , , , , «» . - . « » -, -. , , , ? - .

..: , , , . — , — . ― highload, . , , «» , UNIX-, , — , , . « » — , , .

- , … , , . . - , «», , - , . -, -, . , - IT-, . - , , — , community - . - HighLoad PHP-, PHPClub, SQADays , -, , community , — .

, , HighLoad, . - highload-, . , , … CodeFest, - , DevConf - highload, - «», , highload, , .

, , - , — , , , , — , , , (, ) . , , : Velocity, MySQL Conf – MySQL , MySQL . , MySQL- Percona . PostgreSQL, , «» , , .

.: .

..: . , ?

.: , , -?

..: , , , . : — . , ?

.: , .

..: , , . , ?

.: , .

.: . , , , , , , ― . , , , , . .

..: : , , , , . , , : « , , , , . , “”?» . , , : . , , . , , . , , — « ». , … , . . , , . , — .

, , , , , , , , . , , . , PHP/MySQL-, PHP , - UNIX MySQL, -. highload, , , . — php.feedme.ru , ― .

.: . , , , , , , , . , - . , , , , git, … , , . .

..: , . , — , , - .

.: , . , , .

.: : , - … . -, . - , — . , , . , , — Badoo. itcompot.ru, - podfm.ru, iTunes. . !

..: , .