स्लेक बॉट

Question

शून्य शून्य डाउनटाइम परिनियोजन हम BotKit के साथ बॉट विकसित करते हैं और अब हम न्यूनतम तैनाती डाउनटाइम के साथ समस्या को हल करने का प्रयास करते हैं।

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

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

एक तरफ हम कितने इष्टतम निर्णय प्राप्त कर सकते हैं यदि हम शून्य डाउनटाइम प्राप्त करना चाहते हैं और दूसरी ओर, हम उपयोगकर्ता को एक ही समय में दो उदाहरणों से बातचीत करना चाहते हैं?

निर्णय 1: छोटे मौके को टकराव की संभावना होने की अनुमति देने के लिए, जब दोनों उदाहरण उपयोगकर्ता कमांड का जवाब देंगे।

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

निर्णय 3: समानांतर रन वर्तमान और ऐप या म्यूटेक्स के नए संस्करण के एक इंटरैक्ट के साथ। सामान्य योजनाबद्ध: 1) ऐप का वर्तमान संस्करण चला रहा है 2) तैनाती स्क्रिप्ट ऐप 3 का नया संस्करण शुरू करती है) मैं समय जब ऐप का एक नया संस्करण लगभग चलाता है और आरटीएम-सर्वर से कनेक्ट करने के लिए तैयार होता है, तो यह वर्तमान संस्करण ऐप पर भेजता है आरटीएम कनेक्शन बंद करने के लिए आदेश। 4) ऐप का वर्तमान संस्करण आरटीएम-कनेक्शन 5 बंद करता है) ऐप का नया संस्करण आरटीएम-कनेक्शन

मुझे लगता है कि अन्य अच्छे समाधान हैं।

आप अपने आवेदन में इस समस्या को कैसे हल करेंगे?

Answer 1

(दूसरे उत्तर के लिए खेद है; एक और विचार था।)

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

SET message:<message timestamp> 1 NX PX 30000 

NX विकल्प इस आदेश का मतलब केवल सफल होगा यदि कुंजी पहले से मौजूद नहीं:

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

(PX 30000 सेट तो Redis 30 सेकंड समाप्ति इन कुंजियों से भरा नहीं मिलता है।)

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

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

Answer 2

एक विचार मैं विचार करेगा दो घटकों में अलग है:

1. एक घटक है कि एक WebSocket स्लैक आरटीएम एपीआई से जुड़ा रहता है। यह घटक बस एपीआई से संदेशों को पढ़ता है और उन्हें एक कतार में रखता है। (चलिए इसे "queuer" कहते हैं।)
2. वास्तविक "बॉट," जो कतार से संदेश पढ़ता है और आवश्यकतानुसार प्रतिक्रिया देता है।

आपके बॉट का व्यवहार करने के तरीके के आधार पर, यह सीधे वेब एपीआई का उपयोग कर सकता है या शायद अपने संदेश को आउटबाउंड कतार पर रख सकता है जो "queuer" आरटीएम एपीआई के माध्यम से भेज सकता है।

यह आर्किटेक्चर शायद आपकी समस्या हल करता है ... अब आप उन्नयन के दौरान संक्षेप में बॉट ले सकते हैं-प्रतिक्रियाएं तब तक देरी हो सकती हैं जब तक नया संस्करण चल रहा न हो - या आप एक ही समय में बॉट के दो संस्करण चला सकते हैं और दोनों संस्करणों को एक ही संदेश का जवाब देने से रोकने के लिए कतार के अर्थशास्त्र पर भरोसा करते हैं।