प्रश्न और संदर्भ
यह प्रश्न किसी Kafka सेटिंग को याद रखने के बजाय डिस्ट्रीब्यूटेड ओनरशिप ट्रांसफर का परीक्षण करता है। Eager रीबैलेंसिंग पहले सभी पार्टीशन्स को रीवोक (revoke) करती है, जबकि कोऑपरेटिव रीबैलेंसिंग मेंबर्स को ऐसे पार्टीशन्स बनाए रखने की अनुमति देती है जिन्हें स्थानांतरित करने की आवश्यकता नहीं होती है और केवल माइग्रेशन सेट को रीवोक करती है। एक संपूर्ण उत्तर में मेंबर वर्शन्स, असाइनर प्रोटोकॉल, ऑफ़सेट कमिट्स, फ़ेलियर विंडोज़ और टेलीमेट्री शामिल होते हैं।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप eager और कोऑपरेटिव प्रोटोकॉल के बीच रीवोक और हैंडऑफ़ के अंतर को समझाते हैं।
- क्या आप यह मानने के बजाय कि एक मेंबर अकेले स्विच कर सकता है, एक कम्पैटिबल रोलिंग क्रम की योजना बनाते हैं।
- क्या ओनरशिप, ऑफ़सेट्स, इन-फ़्लाइट कार्य और कमिट का समय आपस में संरेखित (align) हैं।
- क्या क्रैश, टाइमआउट्स, डुप्लिकेट्स, रोलबैक और क्षमता सीमाओं को संभाला गया है।
स्पष्टीकरण के लिए प्रश्न
क्लाइंट वर्शन्स, वर्तमान असाइनर लिस्ट, स्टेटिक मेंबरशिप, प्रति-मैसेज प्रोसेसिंग समय, स्वीकार्य डुप्लिकेट विंडो और रीबैलेंस लेटेंसी बजट की पुष्टि करें। पूछें कि क्या प्रोसेसिंग आइडम्पोटेंट (idempotent) है, क्या सिंक डुप्लिकेट हटाने (deduplication) का समर्थन करता है, और क्या रोलआउट को चरणों में पूरा और रोलबैक किया जा सकता है। पीक स्केलिंग, पार्टीशन काउंट और अलर्ट थ्रेशोल्ड निर्धारित करें।
30-सेकंड की उत्तर रूपरेखा
पहले एक कम्पैटिबल असाइनर लिस्ट बनाए रखते हुए प्रत्येक मेंबर को ऐसे वर्शन में अपग्रेड करें जो कोऑपरेटिव प्रोटोकॉल का समर्थन करता हो। एक बार प्रोटोकॉल समर्थन एकसमान हो जाने के बाद, CooperativeStickyAssignor को पसंदीदा रणनीति के रूप में रोल आउट करें और पुरानी रणनीति को हटा दें। प्रत्येक रीबैलेंस केवल उन्हीं पार्टीशन्स को रीवोक करता है जो स्थानांतरित होते हैं; कंज्यूमर उन्हें फ़ेच करना बंद कर देता है, पूर्ण हो चुके ऑफ़सेट्स को कमिट करता है, और नया ओनर कमिट किए गए ऑफ़सेट्स से कार्य फिर से शुरू करता है। रीबैलेंस काउंट, रीवोक किए गए पार्टीशन्स, प्रोसेसिंग लेटेंसी और डुप्लिकेट्स की निगरानी करें। क्रैश सेशन टाइमआउट और ऑफ़सेट रिकवरी पर निर्भर करता है; रोलबैक एक अन्य रोलिंग बदलाव के माध्यम से पुराने कम्पैटिबल कॉन्फ़िगरेशन को पुनर्स्थापित करता है।
चरण-दर-चरण समाधान
1. प्रोटोकॉल कम्पैटिबिलिटी मैट्रिक्स को परिभाषित करें
असाइनर पर ग्रुप स्तर पर बातचीत (negotiate) होती है, इसलिए केवल एक इंस्टेंस को बदलना पर्याप्त नहीं है। इस पर निर्भर होने से पहले सभी क्लाइंट्स को ऐसे वर्शन में अपग्रेड करें जो कोऑपरेटिव रीबैलेंसिंग को समझता हो। पहले चरण के दौरान एक कम्पैटिबिलिटी प्रविष्टि रखें, फिर ग्रुप तैयार होने के बाद कोऑपरेटिव को प्राथमिकता दें और पुरानी रणनीति को हटा दें:
partition.assignment.strategy=\
org.apache.kafka.clients.consumer.CooperativeStickyAssignor,\
org.apache.kafka.clients.consumer.RangeAssignorप्रत्येक चरण के बाद ग्रुप के नेगोशिएटेड प्रोटोकॉल और असाइनमेंट को वैलिडेट करें; केवल कॉन्फ़िगरेशन फ़ाइल की जाँच करना इस बात का प्रमाण नहीं है कि चल रहा ग्रुप स्विच हो गया है।
2. पार्टीशन रीवोक और हैंडऑफ़ को डिज़ाइन करें
कोऑपरेटिव रीवोक सेट में केवल वही पार्टीशन्स होते हैं जिन्हें स्थानांतरित किया जाना आवश्यक है। रीवोक होने पर, उन पार्टीशन्स को फ़ेच करना बंद करें, वर्तमान सुरक्षित बैच को पूरा करें या छोड़ दें, और पूर्ण हो चुके ऑफ़सेट्स को कमिट करें। उन पार्टीशन्स को प्रोसेस करना जारी रखें जिन्हें रीवोक नहीं किया गया था। नया ओनर कमिट किए गए ऑफ़सेट्स से शुरू करता है, इसलिए बिज़नेस आइडम्पोटेंसी कीज़ या सिंक डिडुप्लिकेशन डुप्लिकेट्स को संभालते हैं।
3. इन-फ़्लाइट कार्य के साथ ऑफ़सेट्स को संरेखित करें
बिज़नेस साइड इफ़ेक्ट के बाद कमिट करें, उससे पहले कभी नहीं। यदि किसी बैच के दौरान रीवोक का सिग्नल मिलता है, तो एक स्टॉप फ़्लैग सेट करें और एक सुरक्षित बिंदु पर समाप्त करें; समयसीमा समाप्त होने पर, फ़ेचिंग रोकें और अधूरे बैच को रिकॉर्ड करें। एसिंक्रोनस प्रोसेसिंग के लिए प्रति-पार्टीशन अनुक्रम ट्रैकिंग की आवश्यकता होती है ताकि केवल एक सन्निहित (contiguous) पूर्ण प्रीफ़िक्स ही कमिट किया जाए।
4. रोलिंग रोलआउट की योजना बनाएं
एक रोलआउट कंट्रोलर मेंबर्स के छोटे बैचों को पुनरारंभ (restart) करता है और प्रत्येक बैच के बाद ग्रुप स्थिरता और लैग रिकवरी की प्रतीक्षा करता है। एक बेसलाइन रिकॉर्ड करें, क्लाइंट्स को अपग्रेड करें, प्रोटोकॉल का निरीक्षण करें, पसंदीदा असाइनर पर स्विच करें, स्केल परिवर्तनों का पूर्वाभ्यास करें, और केवल तभी बैच का आकार बढ़ाएं। सेशन टाइमआउट और max poll interval को एक ही समय में बदलने के बजाय रीबैलेंस स्टॉर्म या लेटेंसी उल्लंघन होने पर रोकें।
5. क्रैश और रोलबैक व्यवहार को डिज़ाइन करें
मेंबर क्रैश के बाद, सेशन टाइमआउट समाप्त होने पर कोऑर्डिनेटर उसके पार्टीशन्स को पुनः आवंटित करता है। नया मेंबर अंतिम कमिट किए गए ऑफ़सेट से कार्य फिर से शुरू करता है, इसलिए क्रैश से पहले के साइड इफ़ेक्ट दोहराए जा सकते हैं। रोलबैक कम्पैटिबिलिटी लिस्ट में पुराने असाइनर को पुनर्स्थापित करता है और उसी रोलिंग क्रम का उपयोग करता है; अभी भी चल रहे किसी नए मेंबर को जबरन न हटाएं। रेस कंडीशन के निदान के लिए जनरेशन, मेंबर आईडी, रीवोक सेट्स और कमिट विफलताओं को रिकॉर्ड करें।
6. क्षमता और टेलीमेट्री गार्डरेल्स जोड़ें
रीबैलेंस फ़्रीक्वेंसी और अवधि, रीवोक किए गए पार्टीशन्स की संख्या, कंज्यूमर लैग, पोल इंटरवल, कमिट लेटेंसी, डुप्लिकेट दर और अनअसाइंड मेंबर्स को ट्रैक करें। एक साथ पुनरारंभ, हॉट पार्टीशन्स, max.poll.interval से अधिक प्रोसेसिंग, नेटवर्क जिटर और मेंबर्स की संख्या के करीब पार्टीशन काउंट का परीक्षण करें। यदि क्षमता कम है, तो जारी रखने से पहले रोलआउट बैच का आकार कम करें या कंज्यूमर्स जोड़ें।
मॉडल उच्च-गुणवत्ता वाला उत्तर
मैं यह सत्यापित करूँगा कि प्रत्येक क्लाइंट कोऑपरेटिव असाइनमेंट का समर्थन करता है, फिर दो-चरणीय रोलिंग कॉन्फ़िगरेशन का उपयोग करूँगा: वर्शन्स को अपग्रेड करते समय एक कम्पैटिबल असाइनर बनाए रखें, और उसके बाद ही CooperativeStickyAssignor को प्राथमिकता दें और पुरानी रणनीति को हटाएं। रीवोक कॉलबैक केवल उन पार्टीशन्स को रोकते हैं जो स्थानांतरित हो रहे हैं, एक सुरक्षित बिंदु को पूरा करते हैं, और एक सन्निहित ऑफ़सेट कमिट करते हैं; बनाए रखे गए पार्टीशन्स जारी रहते हैं। नए ओनर्स कमिट किए गए ऑफ़सेट्स से फिर से शुरू करते हैं, जिसमें आइडम्पोटेंसी डुप्लिकेट्स को संभालती है। एक स्मॉल-बैच कंट्रोलर रीबैलेंस, लैग, पोल इंटरवल्स, कमिट विफलताओं और डुप्लिकेट दर पर नज़र रखता है। क्रैश सेशन टाइमआउट और ऑफ़सेट्स के माध्यम से रिकवर होते हैं, जबकि रोलबैक लाइव मेंबर्स को जबरन हटाने के बजाय उसी कम्पैटिबल रोलिंग क्रम का पालन करता है।
सामान्य गलतियाँ
- केवल एक कंज्यूमर को बदलना और ग्रुप-स्तरीय असाइनर नेगोशिएशन को नज़रअंदाज़ करना।
- कोऑपरेटिव रीबैलेंसिंग को शून्य-विराम (zero pause) मानना, जबकि स्थानांतरित होने वाले पार्टीशन्स का हैंडऑफ़ अभी भी होता है।
- बिज़नेस साइड इफ़ेक्ट से पहले ऑफ़सेट्स को कमिट करना।
- रीवोक के बाद फ़ेच करना या गैर-सन्निहित एसिंक्रोनस परिणामों को कमिट करना।
- एक साथ कई टाइमआउट सेटिंग्स बदलना और कारण संबंधी साक्ष्य (causal evidence) खो देना।
- रीबैलेंस फ़्रीक्वेंसी, रीवोक सेट्स और डुप्लिकेट्स की अनदेखी करते हुए केवल लैग पर नज़र रखना।
फ़ॉलो-अप प्रश्न
क्या कोऑपरेटिव रीबैलेंसिंग शून्य डुप्लिकेट्स की गारंटी देती है?
नहीं। क्रैश, कमिट पुनः प्रयास (retries), और रीवोक सीमाएं काम को दोहरा सकती हैं। लक्ष्य पूरे ग्रुप के पॉज़ को कम करना और डुप्लिकेट विंडो को सीमित करना है; सिंक्स को अभी भी आइडम्पोटेंसी या डिडुप्लिकेशन की आवश्यकता होती है।
प्रत्येक मेंबर के लिए कोऑपरेटिव असाइनमेंट का समर्थन करना क्यों आवश्यक है?
असाइनर प्रोटोकॉल पर ग्रुप द्वारा बातचीत की जाती है। कोई भी मेंबर जो कोऑपरेटिव सेमांटिक्स को पार्स या निष्पादित नहीं कर सकता है, वह नेगोशिएशन को विफल कर सकता है या eager व्यवहार को बाध्य कर सकता है, इसलिए पहले कम्पैटिबल वर्शन्स को रोल आउट किया जाना चाहिए।
यदि प्रोसेसिंग max.poll.interval से अधिक हो जाए तो क्या होगा?
पोल कॉल्स को समय पर रखते हुए छोटे बैचों, एक नियंत्रित एसिंक्रोनस पूल, या सावधानीपूर्वक समीक्षा किए गए पैरामीटर परिवर्तन का उपयोग करें। केवल टाइमआउट बढ़ाने से विफलता का पता लगाने में देरी हो सकती है और पार्टीशन ओनरशिप बढ़ सकती है।
आप रोलबैक सुरक्षा को कैसे वैलिडेट करते हैं?
एक स्टेजिंग ग्रुप में मेंबर क्रैश, नेटवर्क जिटर और कमिट विफलताओं को इंजेक्ट करें। जनरेशन, ऑफ़सेट्स, रीवोक सेट्स और डिडुप्लिकेटेड साइड इफ़ेक्ट्स रिकॉर्ड करें। सत्यापित करें कि पुराना असाइनर अनकमिटेड ऑफ़सेट्स को छोड़े बिना कम्पैटिबिलिटी मैट्रिक्स के भीतर स्थिर हो जाता है।