GH GambleHub

कम विलंबता वास्तुकला

कम विलंबता वास्तुकला क्यों

कम देरी न केवल एक "तेज औसत" है, बल्कि वास्तविक भार के तहत स्थिर पूंछ (p95/p99) है। इसका मार्ग विलंब बजट, कतार/रिट्रे अनुशासन, डेटा और कैश निकटता, सही प्रोटोकॉल/कनेक्शन और सख्त शोषण (सीमा, अवलोकन, गिरावट) है।

लक्ष्यों और बजट में देरी

1. SLO को परिभाषित करें: "p95 ≤ 120ms, p99 ≤ 250 ms, त्रुटि ≤ 0। 3%».

2. बजट इकट्ठा करें: क्लाइंट → एज → क्षेत्र → सेवाएं → स्टोर → उत्तर।

3. सीमा वितरित करें (उदाहरण के लिए, कुल SLO 120 ms p95):
  • क्लाइंट-एज: 15 एमएस
  • किनारे-क्षेत्र: 15ms
  • Gateway/L7: 10 ms
  • व्यावसायिक सेवा: 40 एमएस
  • भंडारण/कैश: 25ms
  • स्टॉक/जिटर: 15 एमएस
💡 किसी भी घटक के पास टाइमआउट और क्षरण योजना होनी चाहिए यदि वह अपने बजट में फिट नहीं होता है।

मेट्रिक्स और पूंछ

प्रत्येक हॉप के माध्यम से और पर p50/p90/p95/p99 मापते हैं।

लेबल द्वारा ब्रेक डाउन: क्षेत्र, विधि, क्लाइंट संस्करण, नेटवर्क प्रकार (मोबाइल/ब्रॉडबैंड), पेलोड आका

कतार के समय और निष्पादन के समय के बीच अंतर करें (लिटिल का नियम देखें: L = W)।

पूंछ-संवेदनशील तकनीक: हेज किए गए अनुरोध (शायद ही कभी और सुरक्षा के साथ), कैस्केडिंग रिट्रेज़का निषेध।

नेटवर्क और प्रोटोकॉल

QUIC/HTTP/3: मोबाइल/रोमिंग पर कम नुकसान, हेड-ऑफ-लाइन के बिना मल्टीप्लेक्सिंग।

टीएलएस 1। 3 और 0-RTT (केवल सुरक्षित पहचान प्रश्नों के लिए)।

DNS: गतिशील मार्गों के लिए छोटा TTL, POP के लिए Anycast।

TCP: 'TCP _ NODELAY' (विवेकपूर्ण), अतिरिक्त 'नागल '/' विलंबित ACK' को अक्षम करना जहां उचित है; जीवित रखें और कनेक्शन की तेजी से वसूली करें।

gRPC/HTTP/2: मल्टीप्लेक्स, फ्लो-कंट्रोल और विंडो सेटिंग्स; छोटे पेलोड पर अत्यधिक संपीड़न से बचें।

कनेक्शन और पूल

डोमेन/गंतव्य द्वारा अलग पूल (ताकि "धीमे पड़ोसी" स्लॉट को दूर न करें)।

वार्म-अप/कीप-लाइव: गर्म कनेक्शन की एक स्थिर संख्या बनाए रखें।

कनेक्शन कोलसिंग (HTTP/2/3) и पुन: उपयोग करें।

टाइमआउट: 'कनेक्ट', 'टीएलएस हैंडशेक', 'अनुरोध', 'निष्क्रिय'। अलग-अलग हॉप्स पर अलग-अलग मूल्य।

डाटा और गणना स्थानीयता

किनारे/क्षेत्र: रीडिंग और आसान गणना उपयोगकर्ता के करीब लाएं (एज नोड्स और क्षेत्रीय तर्क देखें)।

पढ़ें-स्थानीय/लिखें-वैश्विक: पढ़ ने के लिए प्रतिकृति, लिखने के लिए वैश्विक सच।

कैश पदानुक्रम: सीडीएन/एज कैश → क्षेत्रीय केवी/रेडिस → सेवा कैश → स्थानीय इन-प्रोक।

वार्मिंग: रिलीज/स्केलिंग के दौरान गर्म कुंजी लोड कर रहा है।

कम जोखिम वाले डेटा के लिए बासी-जबकि-पुनरुद्धार।

रिपॉजिटरी और इंडेक्स

पहुँच योजनाओं ओ (1 )/ओ (logN) का चयन करें; लगातार प्रश्नों के तहत संकीर्ण सूचकांक रखें।

हॉट-कीज़: 'हैश (आईडी)' द्वारा शार्ड या शानदारता के लिए 'नमक' जोड़ें।

दर्जनों एकल कॉल के बजाय डेटाबेस/कैश (एक उचित आकार के लिए) से बाहर निकलने पर बैचिंग।

OLTP के लिए, सबसे कम संभव लेनदेन; सीरियल लॉक के बजाय रीड-कमिटेड/स्नैपशॉट।

प्रतिस्पर्धी और गैर-अवरोधक

सबसे पहले, कतारों में प्रतीक्षा को समाप्त करें, फिर सीपीयू का अनुकूलन करें।

Async I/O और गैर-अवरोधक ड्राइवर; लॉक-फ्री संरचनाएं जहां उपयुक्त हो।

वैश्विक उत्परिवर्तन से बचें; दानेदार ताले, CAS/versioning।

थ्रेड पूल: फिक्स आकार ताकि आप संदर्भ स्विच में न चलें।

NUMA जागरूकता: सॉकेट, स्थानीय आवंटन के लिए बाध्यकारी धागे।

जेवीएम/जीसी और रनटाइम ट्यूनिंग (यदि लागू हो)

कोड पीढ़ी और आवंटन: कम दुष्प्रभाव - कम जीसी ठहराव।

लक्ष्य ठहराव के साथ आधुनिक जलाशय (G1/ZGC/Shenandoah); बच जाता है और बफर किराए पर लेता है।

कक्षा/डेटा साझाकरण, जेआईटी वार्मिंग, एओटी/देशी-छवि स्टार्ट-निर्भर कार्यों के लिए।

कुल विलंब बजट में जीसी ठहराव हिस्टोग्राम शामिल करें।

कतार, बैकप्रेशर, ओवरलोड सुरक्षा

कतार का आकार = छोटा: लंबी कतारें "सुंदर p50" देती हैं और p99 को मारती हैं।

स्पष्ट बैकप्रेशर: सहेजने की तुलना में "धीमा" जवाब दें।

अनुकूली संगति: बढ़ ती त्रुटि/विलंबता (VEGAS/ढाल एल्गोरिदम, AIMD) के साथ समानतावाद को कम करें।

सर्किट ब्रेकर: पूल और संसाधनों के लिए अपस्ट्रीम क्षरण, बल्कहेड (केबिन कंपनियों) के दौरान तेजी से विफलताएं।

दर सीमा: स्लाइडिंग विंडो/टोकन, प्राथमिकता (उपयोगकर्ता स्तरीय/महत्वपूर्ण-पथ)।

रिट्राई, हेजिंग और पहचान

रेट्राई केवल क्षणिक त्रुटियों के लिए, जिटर और अधिकतम प्रयासों के साथ।

पुनरावृत्ति के लिए आइडेम्पोटेंट ऑपरेशन और 'आइडेम्पोटेंसी-की' की आवश्यकता होती है।

Heded अनुरोध: सीमा के बाद युगल भेजें (उदाहरण के लिए, p95 + 10 ms) और हमेशा अतिरिक्त रद्द करें।

समन्वय के बिना प्रत्येक परत के अंदर कभी पीछे न हटें - एक तूफान प्राप्त करें।

कैचिंग और वार्मिंग

हॉट पाथ ठेठ लोड (इन-प्रोक/एलआरयू) पर नेटवर्क के बिना होगा।

10-60 एस के लिए नकारात्मक कैश ताकि लापता चाबियों को हथौड़ा न दें।

रिलीज/स्केलिंग के दौरान मास वार्मिंग: हॉट की लिस्ट, रीड-फॉरवर्ड, बैकग्राउंड रिफ्रेश।

गिरावट और फॉल्बेक्स

सुंदर गिरावट: विलंबता बढ़ ने पर मामूली विशेषताओं पर वापस काटें (कम विस्तृत प्रतिक्रिया, कोई संवर्धन नहीं)।

सॉफ्ट टाइमआउट: 5xx के बजाय आधार अनुक्रिया/कैश वापस करें।

फेल-ओपन/फेल-बंद - प्रत्येक कॉल के लिए स्पष्ट रूप से दस्तावेज़।

अवलोकन और प्रोफाइलिंग

वितरण ट्रेसिंग: प्रत्येक हॉप, पूंछ-आधारित नमूना पर फैला हुआ है।

RED/USE метрики: दर, त्रुटियां, अवधि/उपयोग, संतृप्ति, त्रुटियां।

शीर्ष-एन "धीमा" मार्ग प्रतिदिन।

कम-ओवरहेड उत्पाद (eBPF/async-profiler/Flight Recorder) में Profilers (alloc/cpu/lock)।

विभिन्न एएसएन/नेटवर्क और मोबाइल चैनलों से सिंथेटिक्स।

निष्पादन परीक्षण

वास्तविक पेलोड और परिवर्तनशीलता के साथ लेटेंसी-एसएलओ परीक्षण (p95/p99)।

अराजकता के परिदृश्य: डीएनएस गिरावट, पैकेट हानि में वृद्धि, टीएलएस देरी, धीमी गति से स्टोर।

कोल्ड-स्टार्ट/स्केल-अप: कैश खाली होने पर रिलीज के पहले मिनट को मापते हैं।

स्क्रिप्ट के अनुसार अलग लोड पूल (पठन/लेखन परीक्षणों में हस्तक्षेप न करें)।

मिनी टेम्पलेट्स

टाइमआउट/रिट्रैक्ट पॉलिसी (छद्म)

yaml timeouts:
connect: 100ms tls_handshake: 150ms request_p95_budget: 80ms retries:
max_attempts: 2 backoff: exp_jitter(10ms..60ms)
retry_on: [CONNECT_ERROR, TIMEOUT, 502, 503, 504]
hedging:
enabled: true threshold: p95 + 10ms cancel_extra_on_first_success: true circuit_breaker:
error_rate_threshold: 5%
p95_threshold_increase: 30%
half_open_after: 10s

पूल और बल्कहेड्स

yaml pools:
checkout:
max_conns: 256 per_host: 64 queue: 8 # small analytics queue:
max_conns: 64 queue: 4

गिरावट के साथ प्रतिक्रिया

json
{
"status": "ok",
"profile": { "id": "u123", "name": "…"},
"recommendations": "degraded, "//disabled the heavy part
"served_from": "edge-cache",
"trace_id": "…"
}

अनुप्रयोग मामलों

iGaming/finance: भुगतान प्राधिकरण <200 ms p95, सीमा/शेष - क्षेत्रीय अनुमानों से पढ़ ना, रिकॉर्ड - संस्करण के साथ पहचान।

विपणन/सिफारिशें: उत्तर <100 ms p95, किनारे पर फ़ीचर फ्लैग्स का कैश, मॉडल - गर्म रास्ते पर प्रारंभिक स्कोरिंग + त्वरित नियम।

मोबाइल क्लाइंट: HTTP/3, आक्रामक पुन: उपयोग कनेक्शन, कम पेलोड (प्रोटोबुफ), सुरक्षा टाइमआउट और ऑफ़ लाइन कैश।

एंटी-पैटर्न

श्रमिकों के सामने लंबी लाइनें: "सुंदर औसत" और p99 को मार डाला।

समन्वय के बिना प्रत्येक परत पर कैस्केड पीछे हटता है।

विकलांगता और वार्मिंग के बिना वैश्विक "मेगा-कैश"।

फजी टाइमआउट (हर जगह "डिफ़ॉल्ट रूप से") - अनियंत्रित पूंछ।

सभी यातायात के लिए एक सामान्य कनेक्शन पूल हेड-ऑफ-लाइन ब्लॉकिंग है।

राजकीय प्रभावों के साथ किनारे पर भारी तर्क।

विकलांग पूंछ टेलीमेट्री - आप "p99 नहीं देख सकते"।

उत्पादन जाँच सूची

  • इसके लिए एक हॉप विलंब बजट और टाइमआउट है।
  • सक्षम HTTP/2/3, टीएलएस 1। 3, कनेक्शन पूल और वार्म-अप।
  • कैश पदानुक्रम, गर्म कुंजी सूची, और वार्म-अप रणनीतियाँ।
  • रीड-लोकल/राइट-ग्लोबल और हॉट की शार्डिंग।
  • स्पष्ट बैकप्रेशर, छोटी कतारें, सर्किट-ब्रेकर और बल्कहेड।
  • जिटर, आइडेम्पोटेंसी, सीमित हेजिंग के साथ रेट्राई।
  • क्षेत्र/संस्करण/क्लाइंट लेबल के साथ ट्रेसिंग; p95/p99 की निगरानी।
  • एएसएन/मोबाइल सिंथेटिक पर्फ परीक्षण, कोल्ड-स्टार्ट और अराजकता स्क्रिप्ट।
  • क्षरण प्रक्रियाएं और फॉलबैक प्रलेखित हैं।
  • p95/p99 वास्तविक भार पर SLO के अनुरूप है।

FAQ

p99 औसत से अधिक महत्वपूर्ण क्यों है?

क्योंकि उपयोगकर्ताओं को पूंछ का सामना करना पड़ ता है, औसत नहीं। p99 दिखाता है "वास्तव में कितना दर्द होता है।"

क्या आपको हर जगह हेजिंग शामिल करना चाहिए?

नहीं, यह नहीं है। यह महत्वपूर्ण रास्तों में दुर्लभ पूंछ के लिए और केवल सख्त सीमा/पहचान के तहत उपयोगी है।

ठंड की शुरुआत को कैसे कम करें?

वार्म अप कैश/कनेक्शन, प्री-कम्पाइल/जेआईटी वार्म अप, आलसी इनिशिएलाइजेशन, गर्म पूल को कम से कम करें।

क्या "नेटवर्क को हराना" संभव है?

आंशिक रूप से: HTTP/3, एज-POP, Anycast, कॉम्पैक्ट पेलोड, कनेक्शन पुन: उपयोग और उचित समय समाप्ति।

कुल

कम विलंबता वास्तुकला व्यवस्था और विषयों की एक प्रणाली है: विलंबता बजट, डेटा निकटता, छोटी कतारें, पूर्वानुमानित रिट्रे, कैश पदानुक्रम, सही प्रोटोकॉल और निर्मम पूंछ अवलोकन। इन सिद्धांतों के बाद, आप स्थिरता और बटुए के बलिदान के बिना p95/p99 को लाइन में रखते हैं।

Contact

हमसे संपर्क करें

किसी भी प्रश्न या सहायता के लिए हमसे संपर्क करें।हम हमेशा मदद के लिए तैयार हैं!

Telegram
@Gamble_GC
इंटीग्रेशन शुरू करें

Email — अनिवार्य है। Telegram या WhatsApp — वैकल्पिक हैं।

आपका नाम वैकल्पिक
Email वैकल्पिक
विषय वैकल्पिक
संदेश वैकल्पिक
Telegram वैकल्पिक
@
अगर आप Telegram डालते हैं — तो हम Email के साथ-साथ वहीं भी जवाब देंगे।
WhatsApp वैकल्पिक
फॉर्मैट: देश कोड और नंबर (उदा. +91XXXXXXXXXX)।

बटन दबाकर आप अपने डेटा की प्रोसेसिंग के लिए सहमति देते हैं।