Ticketing Raft पैरामीटर
| आइटम | मान |
|---|---|
| हार्टबीट अंतराल | 500ms (cluster_heartbeat_ms) |
| अनुत्तरदायी-पहचान समय | 2000ms (cluster_election_timeout_ms) — इतनी देर हार्टबीट न आए तो लीडर को मृत मान लिया जाता है |
| वास्तविक चुनाव विंडो | 1750-2000ms — हर नोड पर यादृच्छिक रूप से बिखेरा जाता है ताकि एक साथ उम्मीदवार (split vote) न बनें। इसका अधिकतम मान ही कॉन्फ़िगर किया गया पहचान समय है |
| लीडर विफलता पर क्लाइंट ठहराव | मापा गया पहचान समय + 0.3-0.5 सेकंड (डिफ़ॉल्ट मानों पर लगभग 2.3-2.5 सेकंड) — पहचान के बाद एक बार पुनर्निर्देशन |
| नोड संख्या | 3 या 5 (कॉन्फ़िग लोड के समय लागू — इसके अलावा कुछ भी बूट होने से इनकार करता है) |
| नोड ID | cluster_peers सूची में इसकी (cluster_self) स्थिति — यही कारण है कि सूची का क्रम हर नोड पर समान होना चाहिए |
| बूटस्ट्रैप | स्टार्टअप के 500ms बाद, हर नोड एक ही सदस्यता के साथ इनिशियलाइज़ होता है — पहले से इनिशियलाइज़ किए गए क्लस्टर में शामिल होने पर अनदेखा किया जाता है |
| लॉग स्टोरेज | इन-मेमोरी (अस्थायी) — एक रीस्टार्ट किया गया नोड प्रतिकृति/स्नैपशॉट के ज़रिए ठीक होता है |
| Lease-समाप्ति पहचान | लीडर हर 100ms में जाँचता है और सर्वसम्मति से Expire कमिट करता है |
wait टाइमआउट सूक्ष्मता | प्रतीक्षा टाइमआउट (T) भी उसी 100ms टिक पर तय होता है — यह 100ms तक देर से आ सकता है |
| लीडर परिवर्तन सूचना | लीडर बदलते ही जुड़े हुए सभी क्लाइंट्स को तुरंत L भेजा जाता है |
हार्टबीट और पहचान समय कैसे चुनें
दोनों मान कॉन्फ़िगरेशन में cluster_heartbeat_ms और cluster_election_timeout_ms से तय होते हैं। पहचान समय (T) ही वह अवधि है जितनी देर लीडर विफल होने पर सेवा रुकी रहती है; वहीं यदि यह बहुत छोटा हो, तो जीवित लीडर को भी गलती से मृत मान लिया जाता है और अनावश्यक चुनाव होते हैं।
| हार्टबीट / T | पहचान विंडो | लीडर kill पर मापी गई अधिकतम देरी | अनुशंसित परिवेश |
|---|---|---|---|
| 100ms / 600ms | 450-600ms | लगभग 0.9 सेकंड | एक ही रैक/AZ, बहुत स्थिर लेटेंसी |
| 100ms / 1000ms | 750-1000ms | लगभग 1.2 सेकंड | एक ही AZ |
| 250ms / 2500ms | 1875-2500ms | लगभग 2.8 सेकंड | मल्टी-AZ |
| 500ms / 2000ms | 1750-2000ms | लगभग 2.4 सेकंड | डिफ़ॉल्ट — मल्टी-AZ के लिए संतुलित |
| 500ms / 5000ms | 3750-5000ms | लगभग 5.3 सेकंड | क्रॉस-रीजन, बहुत उतार-चढ़ाव वाली लेटेंसी |
- सामान्य स्थिति में प्रोसेसिंग लेटेंसी इन मानों से अप्रभावित रहती है (मापा गया: p50 में कोई अंतर नहीं) — ये केवल विफलता के समय की रिकवरी अवधि तय करते हैं।
- फ़ॉलोअर के मरने पर किसी भी मान में क्लाइंट पर कोई प्रभाव नहीं पड़ता। ऊपर बताई देरी केवल लीडर के मरने पर होती है।
- बाध्यता:
cluster_election_timeout_msकम से कम 600ms और हार्टबीट का कम से कम 4 गुना होना चाहिए। (मापा गया है कि भार के दौरान एक बार का शेड्यूलिंग विलंब दो हार्टबीट पूरी तरह निगल जाता है।)
नोड संख्या 3 या 5 ही क्यों
एक कमिट के लिए बहुमत चाहिए। एक सम (even) संख्या वाला कॉन्फ़िगरेशन केवल लागत बढ़ाता है बिना फ़ॉल्ट टॉलरेंस बढ़ाए, इसलिए सर्वर इसे अस्वीकार करता है।
| नोड संख्या | बहुमत | सहनीय समवर्ती विफलताएँ |
|---|---|---|
| 2 | 2 | 0 — एक भी विफलता क्लस्टर को रोक देती है। सिंगल मोड से बेहतर नहीं |
| 3 | 2 | 1 |
| 4 | 3 | 1 — 3 नोड जितना ही, बस लागत अधिक |
| 5 | 3 | 2 |
विफलता व्यवहार सारांश
| स्थिति | व्यवहार |
|---|---|
| किसी गैर-लीडर नोड को क्लाइंट अनुरोध | M (लीडर पता), या यदि लीडर अज्ञात है तो E no_leader |
| लीडर विफलता | 500-1000ms के भीतर नया लीडर चुना जाता है। उस दौरान अनुरोधों को E no_leader मिलता है → क्लाइंट पुनः प्रयास करता है |
| लीडर-परिवर्तन के बीच | लंबित अधिग्रहण अनुरोध M/E no_leader से साफ़ किए जाते हैं, और क्लाइंट नए लीडर के विरुद्ध पुनः प्रयास करता है |
| नोड रीस्टार्ट | खाली स्थिति से बूट होता है → किसी पीयर की लॉग प्रतिकृति/स्नैपशॉट के ज़रिए पकड़ता है |
| बहुमत खोना | कमिट असंभव हो जाते हैं → लेखन रुक जाता है (सुरक्षा पहले), बहुमत बहाल होते ही स्वचालित रूप से फिर शुरू होता है |
शब्दावली
- बहुमत/कोरम (quorum) — सभी नोड्स के आधे से अधिक (3 में से 2, या 5 में से 3)। चूँकि किसी भी निर्णय के लिए कोरम की सहमति चाहिए, विभाजित दो समूह कभी भी एक साथ परस्पर विरोधी निर्णय कमिट नहीं कर सकते।
- चुनाव टाइमआउट (election timeout) — एक फॉलोवर बिना हार्टबीट के कितनी देर प्रतीक्षा करता है इससे पहले कि वह यह निष्कर्ष निकाले कि लीडर मर चुका है और एक चुनाव शुरू करे। एक साथ कई उम्मीदवार बनने से रोकने के लिए यह प्रति नोड यादृच्छिक (randomized) है।