🚲 🤳🏽 🤫 रंग के धागे के लिए हमारा दृष्टिकोण 😾 👐🏿 🤥

हम कंपनी में हमेशा मल्टीथ्रेडिंग के मामलों सहित, आमतौर पर स्वीकृत प्रथाओं का उपयोग करते हुए, हमारे कोड की स्थिरता को बढ़ाने का प्रयास करते हैं। यह उन सभी कठिनाइयों को हल नहीं करता है जो एक बढ़ती हुई लोड लाता है, लेकिन यह समर्थन को सरल करता है - यह कोड की पठनीयता और नई सुविधाओं को विकसित करने की गति भी जीतता है।

अब हमारे पास प्रतिदिन 47,000 उपयोगकर्ता हैं, उत्पादन में लगभग 30 सर्वर, प्रति सेकंड 2,000 एपीआई अनुरोध और दैनिक रिलीज। Miro सेवा 2011 से विकसित हो रही है, और वर्तमान कार्यान्वयन में, उपयोगकर्ता अनुरोधों को विषम सर्वरों के समूह द्वारा समानांतर में संसाधित किया जाता है।

प्रतियोगी अभिगम नियंत्रण सबसिस्टम

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

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

सर्वर से कनेक्ट करते समय, उपयोगकर्ता प्राप्त करने वाली स्ट्रीम में प्रवेश करता है, जिसका एकमात्र कार्य संबंधित बोर्ड की स्थिति से कनेक्शन को बांधना है, जिसके प्रवाह में आगे के सभी काम होंगे।

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

व्यापार / आवेदन और प्रणाली में कोड का विभाजन हमारे आंतरिक सम्मेलन है। यह आपको संचार, शेड्यूलिंग और भंडारण के निम्न-स्तरीय विवरणों, जो सेवा उपकरण हैं, से उपयोगकर्ताओं के लिए सुविधाओं और क्षमताओं के लिए जिम्मेदार कोड के बीच अंतर करने की अनुमति देता है।

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

कार्यों के प्रकार और उनकी दिशा निम्नानुसार दर्शाई जा सकती है:

ऐसा कार्यान्वयन हमें निम्नलिखित समस्याओं को हल करने की अनुमति देता है:

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

प्रवाह रंग

कार्यान्वयन में ऊपर वर्णित सबसिस्टम काफी nontrivial है। डेवलपर को सिस्टम की योजना को ध्यान में रखना होगा और समापन बोर्डों की रिवर्स प्रक्रिया को ध्यान में रखना होगा। बंद करते समय, सभी सदस्यताएं हटाने के लिए आवश्यक है, रजिस्ट्रियों से प्रविष्टियों को हटा दें और यह उन्हीं धाराओं में करें, जिसमें वे आरंभिक थे।

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

इस समस्या को हल करने के लिए, हमने थ्रेड्स को रंगने की विधि का उपयोग किया - यह एक नीति है जिसका उद्देश्य सिस्टम में थ्रेड्स के उपयोग को विनियमित करना है। रंग थ्रेड्स के लिए असाइन किए गए हैं, और विधियाँ थ्रेड के भीतर निष्पादित करने के लिए गुंजाइश निर्धारित करती हैं। यहां रंग एक अमूर्त है, यह किसी भी इकाई हो सकता है, उदाहरण के लिए, एक संलयन। जावा में, एनोटेशन रंग अंकन भाषा के रूप में काम कर सकते हैं:

@Color @IncompatibleColors @AnyColor @Grant @Revoke

नोटों को विधि में जोड़ा जाता है, उनका उपयोग करके आप विधि की वैधता निर्धारित कर सकते हैं। उदाहरण के लिए, यदि किसी विधि का एनोटेशन पीले और लाल रंग की अनुमति देता है, तो पहला धागा विधि को कॉल कर सकता है, और दूसरे के लिए, ऐसी कॉल गलत होगी।

अमान्य रंग निर्दिष्ट किए जा सकते हैं:

आप डायनेमिक्स में थ्रेड विशेषाधिकार जोड़ और हटा सकते हैं:

नीचे दिए गए उदाहरण में एनोटेशन या एनोटेशन की अनुपस्थिति कहती है कि विधि को किसी भी धागे में निष्पादित किया जा सकता है:

एंड्रॉइड डेवलपर्स एनोटेशन, यूआईट्र्रेड, वर्करथ्रेड, आदि के एनोटेशन के इस दृष्टिकोण से परिचित हो सकते हैं।

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

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

 @Aspect public class ThreadAnnotationAspect { @Pointcut("if()") public static boolean isActive() { … //   ,    . , ,    } @Pointcut("execution(@ThreadAnnotation * *.*(..))") public static void annotatedMethod() { } @Around("isActive() && annotatedMethod()") public Object around(ProceedingJoinPoint joinPoint) throws Throwable { Thread thread = Thread.currentThread(); Method method = ((MethodSignature) jp.getSignature()).getMethod(); ThreadAnnotation annotation = getThreadAnnotation(method); if (!annotationMatches(annotation, thread)) { throw new ThreadAnnotationMismatchException(method, thread); } return jp.proceed(); } }

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

पहलुओं पर समाधान कोड में अधिकांश समस्याओं को जल्दी से पाया गया।

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

GuardedBy

रंग की किस्मों में से एक java.util.concurrent से गार्डेडबाय एनोटेशन है। यह खेतों और विधियों तक पहुंच को इंगित करता है, यह दर्शाता है कि सही पहुंच के लिए कौन से ताले आवश्यक हैं।

 public class PrivateLock { private final Object lock = Object(); @GuardedBy (“lock”) Widget widget; void method() { synchronized (lock) { //Access or modify the state of widget } } }

आधुनिक आईडीई भी इस एनोटेशन के विश्लेषण का समर्थन करते हैं। उदाहरण के लिए, IDEA इस संदेश को प्रदर्शित करता है यदि कोड में कुछ गड़बड़ है:

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

हम अभी भी पहलुओं पर कार्यान्वयन का उपयोग करते हैं। यदि आप अधिक सुरुचिपूर्ण समाधान या विश्लेषण उपकरण से परिचित हैं जो आपको सिस्टम परिवर्तनों के लिए इस दृष्टिकोण की स्थिरता को बढ़ाने की अनुमति देता है, तो कृपया इसे टिप्पणियों में साझा करें।

रंग के धागे के लिए हमारा दृष्टिकोण

प्रतियोगी अभिगम नियंत्रण सबसिस्टम

प्रवाह रंग

GuardedBy

More articles: