Jitter के साथ Exponential Backoff

हर बार ज़्यादा प्रतीक्षा करें, और randomise करें

विफलता के तुरंत बाद कई clients retry करें तो वे सेवा पर एक साथ चोट करते हैं और समस्या बढ़ाते हैं (retry storm)। Exponential backoff हर विफल प्रयास के बाद प्रतीक्षा दोगुनी करता है (0.5 s, 1 s, 2 s, 4 s...) सीमा तक, और jitter हर प्रतीक्षा को randomise करता है ताकि clients फैल जाएँ। साथ ही: अधिकतम प्रयासों की सीमा रखें, server भेजे तो retry-after मानें, सिर्फ़ idempotent या सुरक्षित ऑपरेशन retry करें (सादी मॉडल call दोहराना सुरक्षित है, पर ईमेल भेजने वाला tool नहीं), और साफ़ error या fallback के साथ हार मानें। Retries पैसा और समय ख़र्च करते हैं, इसलिए कुल बीता समय भी सीमित करें।

Backoff देरी, चलाकर

मैंने यह सादा-Python (सिर्फ़ standard library) उदाहरण चलाया। सीमाएँ 0.5 s से 8 s की सीमा तक दोगुनी होती हैं। पूर्ण jitter के साथ हर देरी 0 और उसकी सीमा के बीच की random संख्या है (निश्चित seed दोहराव योग्य बनाता है), इसलिए clients एक ही समय पर retry नहीं करते।

import random

def backoff_delays(attempts, base=0.5, cap=8.0, seed=1):
    rnd = random.Random(seed)
    out = []
    for n in range(attempts):
        ceiling = min(cap, base * (2 ** n))          # exponential growth, capped
        out.append(round(rnd.uniform(0, ceiling), 2))   # "full jitter": random up to the ceiling
    return out

print("ceilings:", [min(8.0, 0.5 * 2 ** n) for n in range(6)])
print("delays  :", backoff_delays(6))

Output:

ceilings: [0.5, 1.0, 2.0, 4.0, 8.0, 8.0]
delays  : [0.07, 0.85, 1.53, 1.02, 3.96, 3.6]

पहले SDK retries उपयोग करें

आधिकारिक SDKs पहले से अस्थायी errors कुछ बार retry करते हैं। अपनी परत सिर्फ़ उन ज़रूरतों के लिए जोड़ें जिन्हें वे कवर नहीं करते।

त्वरित जाँच: Backoff में jitter का उद्देश्य क्या है?

• Requests encrypt करना
• Retries तेज़ करना
• Retries फैलाना ताकि सारे clients एक साथ न लौटें
• मॉडल चुनना