RedisPipe - एक साथ अधिक मज़ा

जब मैं सोचता हूं कि आरपीसी ग्राहक कैसे काम करते हैं, तो मुझे एक मजाक याद आता है:

दरबार।
"प्रतिवादी, आपने एक महिला को क्यों मारा?"
- मैं बस में हूं, कंडक्टर ने महिला से संपर्क किया, टिकट खरीदने की मांग की। महिला ने अपना पर्स खोला, अपना पर्स निकाला, अपना पर्स बंद किया, अपना पर्स खोला, अपना पर्स बंद किया, अपना पर्स खोला, उसमें अपना पर्स रखा, अपना पर्स बंद किया, अपने पर्स को खोला, अपने पर्स को खोला, अपना पर्स लिया, अपने पर्स को बंद किया, अपना पर्स खोला और वहां अपना पर्स रखा। , उसका पर्स बंद कर दिया, उसका पर्स खोला, अपना पर्स वहीं रख दिया।
- और क्या?
- कंट्रोलर ने उसे टिकट दिया। एक महिला ने अपना पर्स खोला, अपना पर्स निकाला, अपना पर्स बंद किया, अपना पर्स खोला, अपना पर्स खोला, अपना पर्स वहां रखा, अपना पर्स बंद किया, अपना पर्स खोला, वहां अपना टिकट रखा, अपना पर्स बंद किया, अपना पर्स खोला, अपना पर्स निकाला, अपना पर्स खोला। , पर्स वहाँ रखा, पर्स बंद किया, पर्स खोला, पर्स वहाँ रखा, पर्स बंद कर दिया।
"परिवर्तन करें," नियंत्रक की आवाज आई। महिला ने ... अपना पर्स खोला ...
"हाँ, यह उसे मारने के लिए पर्याप्त नहीं है," अभियोजक खड़ा नहीं है।
"तो मैंने ऐसा किया।"
© एस। अल्टोव

मोटे तौर पर अनुरोध-प्रतिक्रिया प्रक्रिया में एक ही बात होती है, यदि आप इसे पूरी तरह से स्वीकार करते हैं:

• उपयोगकर्ता प्रक्रिया सॉकेट के लिए एक क्रमबद्ध अनुरोध लिखती है, वास्तव में इसे ओएस स्तर पर सॉकेट बफर में कॉपी करना;
  यह एक कठिन ऑपरेशन है, क्योंकि यह एक संदर्भ स्विच बनाने के लिए आवश्यक है (भले ही यह "आसान" हो सकता है);
• जब यह ओएस को लगता है कि नेटवर्क को कुछ लिखा जा सकता है, तो एक पैकेट बनता है (अनुरोध फिर से कॉपी किया जाता है) और नेटवर्क कार्ड पर भेजा जाता है;
• नेटवर्क कार्ड नेटवर्क को पैकेट लिखता है (संभवतः बफरिंग के बाद);
• (जिस तरह से, एक पैकेट को कई बार राउटर में बफर किया जा सकता है);
• अंत में, पैकेट गंतव्य होस्ट पर आता है और नेटवर्क कार्ड पर बफर हो जाता है;
• नेटवर्क कार्ड ऑपरेटिंग सिस्टम को एक सूचना भेजता है, और जब ऑपरेटिंग सिस्टम को समय मिलता है, तो वह पैकेट को उसके बफर में कॉपी कर लेता है और तैयार ध्वज को फाइल डिस्क्रिप्टर पर सेट करता है;
• (आपको जवाब में ACK भेजने के लिए अभी भी याद रखना चाहिए);
• कुछ समय के बाद, सर्वर एप्लिकेशन को पता चलता है कि डिस्क्रिप्टर तैयार है (एपोल का उपयोग करके), और किसी दिन एप्लिकेशन बफर में अनुरोध को कॉपी करता है;
• और अंत में, सर्वर एप्लिकेशन अनुरोध को संसाधित करता है।

जैसा कि आप जानते हैं, प्रतिक्रिया केवल विपरीत दिशा में ठीक उसी तरह से प्रसारित होती है। इस प्रकार, प्रत्येक अनुरोध अपने रखरखाव के लिए ऑपरेटिंग सिस्टम पर ध्यान देने योग्य समय खर्च करता है, और प्रत्येक प्रतिक्रिया उसी समय को फिर से खर्च करती है।

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

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

अनुरोध / प्रतिक्रिया अग्रेषण के इस कठिन कार्य को आसान बनाने के दो तरीके हैं:

1. नेटवर्क कार्ड के लिए सीधी पहुँच का उपयोग करें: DPDK, netmap, PF_RING, आदि।
2. प्रत्येक अनुरोध / प्रतिक्रिया को एक अलग पैकेज के रूप में न भेजें, लेकिन यदि संभव हो तो उन्हें बड़े पैकेजों में मिलाएं, अर्थात, कई अनुरोधों के लिए नेटवर्क के साथ काम करने का ओवरहेड फैलाएं। एक साथ और अधिक मज़ा!

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

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

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

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

जवाब, ज़ाहिर है, "स्पष्ट" है: एक रेडिस सर्वर के समानांतर चलने वाले सभी गोरोइन्ट्स से अनुरोधों को इकट्ठा करके और उन्हें एक कनेक्शन के माध्यम से भेजकर अंतर्निहित पाइप-संग्रह करना।

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

हम रेडिस को यथासंभव प्रभावी रूप से उपयोग करना चाहते थे और इसलिए एक नया "बेहतर" (टीएम) कनेक्टर: रेडिसपाइप लिखने का फैसला किया।

निहित पाइप-बिछाने कैसे करें?

मूल योजना:

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

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

 type Future interface { Resolve(val interface{}) } 

और फिर मूल योजना इस तरह दिखाई देगी:

 type future struct { req Request fut Future } type Conn struct { c net.Conn futmtx sync.Mutex wfutures []future futtimer *time.Timer rfutures chan []future } func (c *Conn) Send(r Request, f Future) { c.futmtx.Lock() defer c.futmtx.Unlock() c.wfutures = append(c.wfutures, future{req: r, fut: f}) if len(c.wfutures) == 1 { futtimer.Reset(100*time.Microsecond) } } func (c *Conn) writer() { for range c.futtimer.C { c.futmtx.Lock() futures, c.wfutures = c.wfutures, nil c.futmtx.Unlock() var b []byte for _, ft := range futures { b = AppendRequest(b, ft.req) } _, _err := ccWrite(b) c.rfutures <- futures } } func (c *Conn) reader() { rd := bufio.NewReader(cc) var futures []future for { response, _err := ParseResponse(rd) if len(futures) == 0 { futures = <- c.rfutures } futures[0].fut.Resolve(response) futures = futures[1:] } } 

बेशक, यह एक बहुत ही सरल कोड है। छोड़े गए:

• कनेक्शन स्थापना;
• I / O टाइमआउट
• पढ़ने / लिखने में त्रुटि से निपटने;
• कनेक्शन को फिर से स्थापित करें;
• नेटवर्क पर भेजने से पहले अनुरोध को रद्द करने की क्षमता;
• मेमोरी आवंटन का अनुकूलन (बफर और वायदा सरणियों का पुन: उपयोग)।

वास्तविक कोड में किसी भी I / O त्रुटि (एक टाइमआउट सहित) भविष्य के सभी त्रुटियों का एक समाधान होता है जो भेजे गए अनुरोधों और भेजे जाने के लिए प्रतीक्षा करता है।
कनेक्शन परत अनुरोध के पुन: प्रयास में शामिल नहीं है, और यदि अनुरोध को पुनः प्राप्त करने के लिए आवश्यक (और संभव है), यह अमूर्त के उच्च स्तर पर किया जा सकता है (उदाहरण के लिए, नीचे वर्णित रेडिस क्लस्टर समर्थन के कार्यान्वयन में)।

Remarque। प्रारंभ में, सर्किट थोड़ा अधिक जटिल लग रहा था। लेकिन प्रयोगों की प्रक्रिया में इस तरह के विकल्प को सरल बनाया गया।

टिप्पणी 2. Future.esolve पद्धति पर बहुत सख्त आवश्यकताएं लगाई गई हैं: यह जितना संभव हो उतनी तेजी से होना चाहिए, व्यावहारिक रूप से गैर-अवरुद्ध और किसी भी मामले में आतंक नहीं। यह इस तथ्य के कारण है कि इसे पाठक चक्र में सिंक्रोनस कहा जाता है, और कोई भी "ब्रेक" अनिवार्य रूप से गिरावट की ओर ले जाएगा। Future.Resolve का कार्यान्वयन आवश्यक न्यूनतम रैखिक कार्रवाई करना चाहिए: अपेक्षा को जगाने के लिए; शायद त्रुटि को संभालें और एक एसिंक्रोनस रिट्री भेजें (क्लस्टर समर्थन को लागू करने में उपयोग किया जाता है)।

प्रभाव

एक अच्छा बेंचमार्क आधा लेख है!

एक अच्छा बेंचमार्क वह है जो प्रेक्षित प्रभावों के संदर्भ में उपयोग करने के लिए जितना संभव हो उतना करीब है। और यह करना आसान नहीं है।

बेंचमार्क विकल्प , जो, मुझे ऐसा लगता है, वास्तविक के समान सुंदर दिखता है:

• मुख्य "स्क्रिप्ट" 5 समानांतर ग्राहकों का अनुकरण करता है,
• प्रत्येक "क्लाइंट" में, प्रत्येक 300-1000 "वांछित" आरपीएस के लिए, गोरोइनट ट्रिगर किया जाता है (1000 आरपीएस के लिए 3 गॉरुटिन ट्रिगर होते हैं, 124 गोरूटिन 128000 आरपीएस के लिए चलाए जाते हैं),
• गोरुटिन दर सीमक के एक अलग उदाहरण का उपयोग करता है और 5 से 15 अनुरोधों से - यादृच्छिक श्रृंखला में अनुरोध भेजता है।

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

परीक्षण चार-कोर AWS c5-2xlarge उदाहरण पर हुआ। रेडिस संस्करण 5.0 है।

वांछित क्वेरी तीव्रता, जिसके परिणामस्वरूप कुल तीव्रता और CPU मूली द्वारा खपत का अनुपात:

आप देख सकते हैं कि क्लासिकल स्कीम (रिक्वेस्ट / रिस्पांस + कनेक्शन पूल) के अनुसार काम करने वाले एक कनेक्टर के साथ, रेडिस बहुत जल्दी प्रोसेसर कोर को खा जाता है, जिसके बाद 190 krps से अधिक के लिए एक असंभव कार्य हो जाता है।

RedisPipe आपको Redis से सभी आवश्यक शक्ति को निचोड़ने की अनुमति देता है। और जितना अधिक हम समानांतर अनुरोधों को इकट्ठा करने के लिए रुकते हैं, उतना ही कम Redis CPU का उपभोग करता है। एक ठोस लाभ ग्राहक से पहले ही 4krps (कुल मिलाकर 20krps) में प्राप्त होता है, यदि 150 माइक्रोसेकंड का एक ठहराव उपयोग किया जाता है।

यदि Redis CPU पर टिकी हुई है, तब भी यदि विराम का उपयोग स्पष्ट रूप से नहीं किया जाता है, तो विलंब स्वयं ही प्रकट होता है। इसके अलावा, अनुरोध ऑपरेटिंग सिस्टम द्वारा बफ़र किए जाने लगते हैं। यह RedisPipe को सफलतापूर्वक निष्पादित अनुरोधों की संख्या बढ़ाने की अनुमति देता है जब क्लासिक कनेक्टर पहले से ही अपने पंजे को कम कर रहा है।

यह मुख्य परिणाम है, जिसके लिए एक नया कनेक्टर बनाने की आवश्यकता थी।

तब, क्लाइंट पर CPU खपत और विलंबित अनुरोधों के साथ क्या होता है?

आप देख सकते हैं कि छोटे रैप पर रेडिसपाइप स्वयं "प्रतियोगी" की तुलना में अधिक सीपीयू का उपभोग करता है, खासकर अगर एक छोटे से ठहराव का उपयोग किया जाता है। यह मुख्य रूप से गो में टाइमर के कार्यान्वयन और ऑपरेटिंग सिस्टम में उपयोग किए जाने वाले सिस्टम कॉल के कार्यान्वयन के कारण होता है (लिनक्स पर यह futexsleep है), क्योंकि "नो पॉज़" मोड में अंतर काफी कम है।

बढ़ते समय के साथ, टाइमर के लिए ओवरहेड नेटवर्किंग के लिए कम ओवरहेड द्वारा ऑफसेट किया जाता है, और प्रति क्लाइंट 16 krps के बाद, 150 माइक्रोसेकंड के ठहराव के साथ RedisPipe का उपयोग मूर्त लाभ लाने के लिए शुरू होता है।

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

जब तक रेडिस सीपीयू में नहीं चलता है, तब तक विलंबता का अनुरोध करता है, ज़ाहिर है, ठहराव का उपयोग करने से ग्रस्त है। यह समझौता जानबूझकर संबंधक में रखा गया है। हालाँकि, यह व्यापार बंद केवल ध्यान देने योग्य है यदि Redis और क्लाइंट एक ही भौतिक होस्ट पर हैं। नेटवर्क टोपोलॉजी के आधार पर, पड़ोसी मेजबान की एक गोल यात्रा एक सौ माइक्रोसेकंड से एक मिलीसेकंड तक हो सकती है। तदनुसार, पहले से ही नौ गुना (0.26 / 0.03) के बजाय देरी में अंतर तीन गुना (0.36 / 0.13) हो जाता है या केवल दसियों प्रतिशत (1.26 / 1.03) के एक जोड़े द्वारा मापा जाता है।

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

विकास को लोड करने के लिए मुख्य सकारात्मक परिणाम एक सहिष्णुता है: यदि अचानक सेवा पर भार एन बार बढ़ जाता है, तो रेडिस सीपीयू को उसी एन गुना अधिक उपभोग नहीं करेगा। 160 krps से 640 krps तक के लोड को चौगुनी करने के लिए, Redis ने केवल 1.6 गुना अधिक CPU खर्च किया, खपत 29 से 46% तक बढ़ गई। यह हमें डरने की अनुमति नहीं देता है कि रेडिस अचानक झुक जाएगा। आवेदन की मापनीयता भी कनेक्टर के संचालन और नेटवर्क कनेक्टिविटी की लागत (रीड: एसवाईएस सीपीयू लागत) द्वारा निर्धारित नहीं की जाएगी।

Remarque। बेंचमार्क कोड छोटे मूल्यों के साथ संचालित होता है। अपने विवेक को साफ करने के लिए, मैंने परीक्षण को 768 बाइट्स के आकार के साथ दोहराया। मूली द्वारा सीपीयू की खपत में स्पष्ट रूप से वृद्धि हुई (150, के ठहराव पर 66% तक), और एक क्लासिक कनेक्टर के लिए छत 170 krps तक गिरती है। लेकिन सभी मनाया अनुपात समान रहे, और इसलिए निष्कर्ष।

समूह

स्केलिंग के लिए हम रेडिस क्लस्टर का उपयोग करते हैं। यह हमें कैश के रूप में न केवल Redis का उपयोग करने की अनुमति देता है, बल्कि एक अस्थिर भंडारण के रूप में भी और एक ही समय में क्लस्टर को विस्तारित / संपीड़ित करने पर डेटा खोने के लिए नहीं।

रेडिस क्लस्टर स्मार्ट क्लाइंट सिद्धांत का उपयोग करता है, अर्थात क्लाइंट को स्वयं क्लस्टर की स्थिति की निगरानी करनी चाहिए, और "मूली" द्वारा लौटाए गए सहायक त्रुटियों का भी जवाब देना चाहिए जब "गुलदस्ता" उदाहरण से उदाहरण के लिए चलता है।

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

तदनुसार, नए कनेक्टर को इस त्रुटि को रोकने का काम सौंपा गया था। क्वेरी निष्पादन पथ पर क्लस्टर स्थिति के साथ सभी इंटरैक्शन को यथासंभव लॉक-फ़्री बनाया गया है:

• क्लस्टर स्थिति व्यावहारिक रूप से अपरिवर्तनीय बनाई गई है, और परमाणुओं द्वारा स्वादित कई उत्परिवर्तन नहीं हैं
• राज्य तक पहुँच atomic.StorePointer / atomic.LoadPointer का उपयोग करके होती है, और इसलिए इसे अवरुद्ध किए बिना प्राप्त किया जा सकता है।

इस प्रकार, क्लस्टर स्टेट अपडेट के दौरान भी, अनुरोध लॉक पर प्रतीक्षा किए बिना पिछले राज्य का उपयोग कर सकते हैं।

 // storeConfig atomically stores config func (c *Cluster) storeConfig(cfg *clusterConfig) { p := (*unsafe.Pointer)(unsafe.Pointer(&c.config)) atomic.StorePointer(p, unsafe.Pointer(cfg)) } // getConfig loads config atomically func (c *Cluster) getConfig() *clusterConfig { p := (*unsafe.Pointer)(unsafe.Pointer(&c.config)) return (*clusterConfig)(atomic.LoadPointer(p)) } func (cfg *clusterConfig) slot2shardno(slot uint16) uint16 { return uint16(atomic.LoadUint32(&cfg.slots[slot])) } func (cfg *clusterConfig) slotSetShard(slot, shard uint16) { atomic.StoreUint32(&cfg.slots[slot], shard) } 

क्लस्टर स्थिति को हर 5 सेकंड में अपडेट किया जाता है। लेकिन अगर क्लस्टर अस्थिरता का संदेह है, तो अपडेट मजबूर है:

 func (c *Cluster) control() { t := time.NewTicker(c.opts.CheckInterval) defer t.Stop() // main control loop for { select { case <-c.ctx.Done(): // cluster closed, exit control loop c.report(LogContextClosed{Error: c.ctx.Err()}) return case cmd := <-c.commands: // execute some asynchronous "cluster-wide" actions c.execCommand(cmd) continue case <-forceReload: // forced mapping reload c.reloadMapping() case <-tC: // regular mapping reload c.reloadMapping() } } } func (c *Cluster) ForceReloading() { select { case c.forceReload <- struct{}{}: default: } } 

यदि मूली से प्राप्त MOVED या ASK प्रतिक्रिया में एक अज्ञात पता होता है, तो कॉन्फ़िगरेशन के लिए इसका अतुल्यकालिक जोड़ शुरू किया जाता है। (मुझे खेद है, मुझे पता नहीं था कि कोड को कैसे सरल बनाया जाए, क्योंकि यहाँ लिंक है ।) यह ताले के उपयोग के बिना नहीं था, लेकिन उन्हें थोड़े समय के लिए लिया जाता है। सरणी में कॉलबैक को सहेजकर मुख्य अपेक्षा का एहसास किया जाता है - समान भविष्य, साइड व्यू।

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

 func (c *Cluster) connForSlot(slot uint16, policy ReplicaPolicyEnum) (*redisconn.Connection, *errorx.Error) { var conn *redisconn.Connection cfg := c.getConfig() shard := cfg.slot2shard(slot) nodes := cfg.nodes var addr string switch policy { case MasterOnly: addr = shard.addr[0] // master is always first node := nodes[addr] if conn = node.getConn(c.opts.ConnHostPolicy, needConnected); conn == nil { conn = node.getConn(c.opts.ConnHostPolicy, mayBeConnected) } case MasterAndSlaves: n := uint32(len(shard.addr)) off := c.opts.RoundRobinSeed.Current() for _, needState := range []int{needConnected, mayBeConnected} { mask := atomic.LoadUint32(&shard.good) // load health information for ; mask != 0; off++ { bit := 1 << (off % n) if mask&bit == 0 { // replica isn't healthy, or already viewed continue } mask &^= bit addr = shard.addr[k] if conn = nodes[addr].getConn(c.opts.ConnHostPolicy, needState); conn != nil { return conn, nil } } } } if conn == nil { c.ForceReloading() return nil, c.err(ErrNoAliveConnection) } return conn, nil } func (n *node) getConn(policy ConnHostPolicyEnum, liveness int) *redisconn.Connection { for _, conn := range n.conns { switch liveness { case needConnected: if c.ConnectedNow() { return conn } case mayBeConnected: if c.MayBeConnected() { return conn } } } return nil } 

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

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

कस्टम भविष्य क्यों लपेटें? सबसे पहले, क्लस्टर मोड में, "मूली" अद्भुत "त्रुटियों" को वापस ले जाती है, जो आपको आवश्यक कुंजी के लिए जाने की जानकारी के साथ MOVED और ASK, और इस तरह की त्रुटि प्राप्त होने पर, आपको किसी अन्य होस्ट के अनुरोध को दोहराने की आवश्यकता है। दूसरे, चूँकि हमें अभी भी पुनर्निर्देशन तर्क को लागू करने की आवश्यकता है, तो एक I / O त्रुटि के साथ अनुरोध को फिर से क्यों न करें (निश्चित रूप से, केवल अगर रीड अनुरोध):

 type request struct { c *Cluster req Request cb Future slot uint16 policy ReplicaPolicyEnum mayRetry bool } func (c *Cluster) SendWithPolicy(policy ReplicaPolicyEnum, req Request, cb Future) { slot := redisclusterutil.ReqSlot(req) policy = c.fixPolicy(slot, req, policy) conn, err := c.connForSlot(slot, policy, nil) if err != nil { cb.Resolve(err) return } r := &request{ c: c, req: req, cb: cb, slot: slot, policy: policy, mayRetry: policy != MasterOnly || redis.ReplicaSafe(req.Cmd), } conn.Send(req, r, 0) } func (r *request) Resolve(res interface{}, _ uint64) { err := redis.AsErrorx(res) if err == nil { r.resolve(res) return } switch { case err.IsOfType(redis.ErrIO): if !r.mayRetry { // It is not safe to retry read-write operation r.resolve(err) return } fallthrough case err.HasTrait(redis.ErrTraitNotSent): // It is request were not sent at all, it is safe to retry both readonly and write requests. conn, err := rcconnForSlot(r.slot, r.policy, r.seen) if err != nil { r.resolve(err) return } conn.Send(r.req, r) return case err.HasTrait(redis.ErrTraitClusterMove): addr := movedTo(err) ask := err.IsOfType(redis.ErrAsk) rcensureConnForAddress(addr, func(conn *redisconn.Connection, cerr error) { if cerr != nil { r.resolve(cerr) } else { r.lastconn = conn conn.SendAsk(r.req, r, ask) } }) return default: // All other errors: just resolve. r.resolve(err) } } 

यह भी एक सरलीकृत कोड है। रिट्रीट की संख्या पर प्रतिबंध, समस्याग्रस्त कनेक्शन का संस्मरण आदि।

आराम

अतुल्यकालिक अनुरोध, भविष्य एक सुपरक्यूल है! लेकिन बहुत असहज।

इंटरफ़ेस सबसे महत्वपूर्ण चीज है। आप एक अच्छा इंटरफ़ेस है, तो आप कुछ भी बेच सकते हैं। यही कारण है कि Redis और MongoDB ने अपनी लोकप्रियता हासिल की है।

इसलिए, हमारे अतुल्यकालिक अनुरोधों को सिंक्रोनस में बदलना आवश्यक है।

 // Sync provides convenient synchronous interface over asynchronous Sender. type Sync struct { S Sender } // Do is convenient method to construct and send request. // Returns value that could be either result or error. func (s Sync) Do(cmd string, args ...interface{}) interface{} { return s.Send(Request{cmd, args}) } // Send sends request to redis. // Returns value that could be either result or error. func (s Sync) Send(r Request) interface{} { var res syncRes res.Add(1) sSSend(r, &res) res.Wait() return res.r } type syncRes struct { r interface{} sync.WaitGroup } // Resolve implements Future.Resolve func (s *syncRes) Resolve(res interface{}) { sr = res s.Done() } // Usage func get(s redis.Sender, key string) (interface{}, error) { res := redis.Sync{s}.Do("GET", key) if err := redis.AsError(res); err != nil { return nil, err } return res, nil } 

AsError एक त्रुटि प्राप्त करने के लिए एक देशी गो-वे की तरह नहीं दिखता है। लेकिन मुझे यह पसंद है, क्योंकि मेरे विचार में, परिणाम का Result<T,Error> , और AsError एक AsError मिलान पैटर्न है।

कमियों

लेकिन, दुर्भाग्य से, इस भलाई में मरहम में एक मक्खी है।

Redis प्रोटोकॉल में पुन: व्यवस्थित अनुरोध शामिल नहीं हैं। और इसके साथ ही, इसमें BLPOP, BRPOP जैसे अवरोधक अनुरोध हैं।

यह एक विफलता है।

जैसा कि आप जानते हैं, यदि ऐसा कोई अनुरोध अवरुद्ध है, तो यह निम्नलिखित सभी अनुरोधों को रोक देगा। और इसके बारे में कुछ भी नहीं किया जाना है।

एक लंबी चर्चा के बाद, RedisPipe में इन अनुरोधों के उपयोग को प्रतिबंधित करने का निर्णय लिया गया।

बेशक, अगर आपको वास्तव में इसकी आवश्यकता है, तो आप कर सकते हैं: पैरामीटर ScriptMode: true बेनकाब करें ScriptMode: true , और यह सब आपके विवेक पर है।

विकल्प

वास्तव में, अभी भी एक विकल्प है जिसका मैंने उल्लेख नहीं किया था, लेकिन जो जानकार पाठकों ने सोचा था, वह क्लस्टर कैश्स ट्वेमप्रोक्सी का राजा है।

वह रेडिस के लिए करता है जो हमारा कनेक्टर करता है: यह एक क्रूड और स्मेलस "अनुरोध / प्रतिक्रिया" को एक सौम्य "पाइप-बिछाने" में बदल देता है।

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

प्रभाव

मेरे पास एक लेख लिखने का समय नहीं था, और रेडिसपाइप से तरंगें पहले ही जा चुकी हैं। Radix.v3 में एक पैच अपनाया गया है जो उनके पूल में पाइपलाइनिंग जोड़ता है:

RedisPipe की जाँच करें और पता लगाएँ कि क्या इसकी अंतर्निहित पाइपलाइनिंग / बैचिंग की रणनीति को शामिल किया जा सकता है
पूल में कमांड के लिए स्वचालित पाइपलाइनिंग

वे गति में थोड़ा हीन हैं (उनके बेंचमार्क को देखते हुए; लेकिन मुझे यकीन नहीं है)। लेकिन उनका लाभ यह है कि वे पूल से अन्य कनेक्शन के लिए ब्लॉकिंग कमांड भेज सकते हैं।

निष्कर्ष

यह जल्द ही एक साल पहले ही है कि RedisPipe हमारी सेवा की प्रभावशीलता में योगदान देता है।
और किसी भी "गर्म दिनों" की प्रत्याशा में, संसाधनों में से एक, जिसकी क्षमता चिंता का कारण नहीं है, रेडिस सर्वर पर सीपीयू है।

कोष
बेंचमार्क