Die Thundering Herd abwehren
Lernen Sie, wie Cache-Stampedes entstehen, wenn beliebte Schlüssel ablaufen, und welche Techniken sie verhindern: Request Coalescing, Sperren, vorzeitige Neuberechnung und TTLs mit Jitter.
Die Thundering Herd abwehren ist eine kostenlose Caching Strategies: Redis + CDN + Edge Computing-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Caching Strategies: Redis + CDN + Edge Computing-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Caching Strategies: Redis + CDN + Edge Computing-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
The Thundering Herd Problem
When a hot cache key expires, every concurrent request misses at once and rushes the origin together. This cache stampede (or thundering herd) can overwhelm the database in an instant.
Why It Is Dangerous
A single popular item serving 10,000 requests/second normally hits the cache. The moment it expires, those 10,000 requests all hit the database simultaneously, often causing a spike that takes the origin down.
Cause: Synchronized Expiry
The root cause is many keys (or many requests on one key) expiring at the same moment. The fix strategies all aim to spread or serialize the resulting recomputation.
Fix 1: Request Coalescing
Let only the first request recompute the value; everyone else waits for that result. This is also called single-flight.
in_flight = {}
def get(key, compute):
if key in in_flight:
return 'waiting for in-flight result'
in_flight[key] = True
return compute()
print(get('hot', lambda: 'computed once'))Fix 2: Mutex Lock
Use a distributed lock (e.g. a Redis key with NX) so only one process recomputes. Others briefly serve stale data or retry after a short wait.
lock = None
def acquire_lock(holder):
global lock
if lock is None:
lock = holder
return True
return False
print(acquire_lock('worker-1'))
print(acquire_lock('worker-2'))Fix 3: Jittered TTL
Add randomness to each entry's TTL so they do not all expire together. A base TTL plus random jitter spreads recomputation over time.
import random
base_ttl = 300
jitter = random.randint(0, 60)
print('TTL for this entry:', base_ttl + jitter, 'seconds')Fix 4: Early Recomputation
Refresh a value before it expires. When an entry is close to its TTL, a background task (or a probabilistic check) recomputes it so it never actually goes cold for users.
Probabilistic Early Expiration
A clever trick: as a key nears expiry, give each request a small, growing probability of recomputing early. One lucky request refreshes the value while others still serve the cached copy.
import random
time_left = 5
beta = 1.0
should_refresh = random.random() < (1 / max(time_left, 1)) * beta
print('Refresh early?', should_refresh)Fix 5: Serve Stale While Revalidating
Return the expired value immediately while a background job fetches fresh data. Users get a fast (slightly stale) response and the origin sees only one refresh request.
Combining Defenses
Real systems layer these: jittered TTLs to avoid synchronized expiry, plus coalescing or a lock to serialize the inevitable misses, plus stale-while-revalidate for the best user experience.
Watch for Cache Penetration Too
A related issue is penetration: requests for keys that never exist always miss and hit the origin. Cache negative results (or use a bloom filter) so missing keys are also absorbed.
Quick Check
Which technique prevents a cache stampede by ensuring only one request recomputes the value while the rest wait for that result?
Recap
You learned to defend against the thundering herd:
- Stampedes happen when hot keys expire and many requests miss at once.
- Coalescing and locks serialize recomputation.
- Jittered TTLs and early recomputation spread the load.
- Stale-while-revalidate keeps responses fast.
Combine these to keep your origin safe under load.
Häufig gestellte Fragen
Ist die Lektion „Die Thundering Herd abwehren“ kostenlos?
Ja — der vollständige Text von „Die Thundering Herd abwehren“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Caching Strategies: Redis + CDN + Edge Computing-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Caching Strategies: Redis + CDN + Edge Computing-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Die Thundering Herd abwehren“?
Lernen Sie, wie Cache-Stampedes entstehen, wenn beliebte Schlüssel ablaufen, und welche Techniken sie verhindern: Request Coalescing, Sperren, vorzeitige Neuberechnung und TTLs mit Jitter. Du übst Caching Strategies: Redis + CDN + Edge Computing mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Caching Strategies: Redis + CDN + Edge Computing zu starten?
Keine Vorkenntnisse erforderlich. Caching Strategies: Redis + CDN + Edge Computing auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Die Thundering Herd abwehren“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Caching Strategies: Redis + CDN + Edge Computing-Lektion Code schreiben und ausführen?
Ja. Jede Caching Strategies: Redis + CDN + Edge Computing-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Gängige Caching-Patterns
- Strategien zur Cache-Invalidierung
- Richtlinien zur Cache-Auslagerung
- Die Thundering Herd abwehren