Bulkhead
Ein Bulkhead isoliert Ressourcen wie Threads, Verbindungen oder Worker-Pools. Eine überlastete Funktion verbraucht dann vor allem ihr eigenes Kontingent.
- KontingentEigener Ressourcenanteil je Funktion.
- IsolationÜberlast bleibt im eigenen Pool.
- DimensionierungKontingent muss zur Last passen.
Einordnung
Warum das wichtig ist
Teilen sich alle Funktionen dieselben Threads oder Verbindungen, zieht eine langsame Funktion die übrigen mit. Getrennte Kontingente begrenzen den Schaden auf einen Bereich. Backpressure und Breaker vertiefen eigene Bausteine.
Dieser Baustein behandelt Ressourcenisolation. Backpressure reguliert die Annahme neuer Arbeit; Circuit Breaker begrenzt Aufrufe an gestörte Abhängigkeiten.
Auf einen Blick · Getrennte Abteile je Abhängigkeit
Verzögerte Rechnungen im Worker-Pool
Der modulare Shop nutzt einen Worker-Pool für Rechnungen und einen eigenen Pool für Bestellbestätigungen. Verzögerte Rechnungen belegen nicht die Bestellbestätigungskapazität.
So liest du das Bild
- Kontingent Bei „getrennte Pools“ steht die Kapazität als Rechnungspool und Bestätigungspool getrennt da.
- Isolation Rechnungsaufträge sind rot, die Bestätigung von B-1042 bleibt grün.
- Dimensionierung Der Bestätigungspool bleibt frei, solange sein Kontingent zur Last passt.
- läuftRechnungsaufträgeläuft normal
- läuftBestätigung B-1042wird sofort verarbeitet
- läuftWorker-Kapazitätgenug Worker frei
0Wartende Bestätigungen
Beide Funktionen kommen mit ihrer Kapazität aus. Der Unterschied zeigt sich erst bei verzögerten Rechnungen.
Nutzen & Grenzen
Hilft, wenn
- Getrennte Antwortziele und Ressourcenprofile profitieren von eigenen Kontingenten bei Spitzenlast.
- Mandanten oder Prioritäten in einer gemeinsamen Plattform lassen sich durch begrenzte Kapazitätsanteile fair bedienen.
Grenzen
- Gemeinsam genutzte Engpässe unterlaufen die logische Trennung; prüfe CPU, Speicher, Pools, Locks und Netz unter gleichzeitiger Last.
- Starre Reserven lassen Kapazität ungenutzt; miss die Auslastung des Rechnungspools und lege eine Obergrenze für geteilte Restkapazität fest.
- Die Trennung verhindert Ausbreitung, aber nicht den Ausfall im eigenen Pool; ein Breaker schützt zusätzlich vor dem Dauerzustand.
In der Praxis
- Knappen Engpass lokalisieren. Erfasse Ressourcennutzung je Aufgabenklasse und bestimme, welcher Pool zuerst erschöpft. Verfolge die Trennung bis zu Datenbank, CPU und Netz. Das Ergebnis zeigt, an welchen Stellen Kontingente Schutzwirkung entfalten müssen.
- Kontingente und Queuegrenzen festlegen. Bestimme Mindest- und Höchstkapazität, maximale Wartearbeit und eine Prioritätsregel. Entscheide, ob neue Arbeit wartet oder kontrolliert abgewiesen wird. Damit bleibt die Auslastung begrenzt und die Reaktion bei Erschöpfung vorhersehbar.
- Isolation messen und anpassen. Prüfe Antwortzeiten, Ablehnungen und gemeinsam genutzte Ressourcen bei gleichzeitiger Überlast. Vergleiche Schutzwirkung mit ungenutzter Reserve und justiere Kontingente anhand dieser Messung. Das Ergebnis ist eine empirisch begründete Aufteilung, deren Kontingente die gemessene Schutzwirkung abbilden.
Ausführliche Erklärung lesen
Ein Bulkhead teilt knappe Ressourcen nach Funktion, Mandant oder Priorität in getrennte Kontingente. Worker, Verbindungen, Threads und Warteschlangen können jeweils eigene Grenzen erhalten. Erschöpfung bleibt dadurch zunächst in der betroffenen Klasse. Die Trennung ergänzt den zustandsbasierten Schutz eines Circuit Breaker und die Zuflusssteuerung durch Backpressure.
Isolation wirkt nur bis zu den tatsächlich geteilten Engpässen. Separat gestartete Worker können weiterhin dieselbe CPU, Datenbank oder Netzwerkgrenze beanspruchen. Kontingentgröße, Queuegrenze und Ablehnungsverhalten müssen deshalb gemeinsam entworfen werden. Reservierte Kapazität begrenzt Konkurrenz, kann aber bei ungleicher Nutzung brachliegen; Messwerte helfen, Schutz und Auslastung auszubalancieren.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wird die Bestätigung von B-1042 bei verzögerten Rechnungen und getrennten Pools verarbeitet?
Lösung mit Begründung ansehen
Ja, sofort. Der Rechnungspool ist voll, der Bestätigungspool bleibt frei.
AnwendenAuf eine neue Lage übertragen
Viele langsame Rechnungsaufträge belegen den Rechnungspool. Der Kunde bestellt B-1042. Wird die Bestellbestätigung verarbeitet?
Lösung mit Begründung ansehen
Ja, soweit der Bestätigungspool für den Bedarf passend dimensioniert ist. Er hat ein eigenes Kontingent, das die Rechnungen nicht verbrauchen können.
BewertenEine Alternative abwägen
Das Team nutzt einen gemeinsamen Pool statt zwei getrennter. Was spricht dafür, was dagegen?
Lösung mit Begründung ansehen
Dafür: Freie Kapazität steht allen Aufgaben zur Verfügung, und es gibt weniger Kontingente zu pflegen. Dagegen: Langsame Rechnungen können die Bestätigung verdrängen. Der Bulkhead nimmt genau dieses Risiko heraus.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microsoft – Bulkhead pattern (öffnet in neuem Tab)Beschreibt Ressourcenisolation zwischen Verbrauchern und Abhängigkeiten.
- Resilience4j – Bulkhead (öffnet in neuem Tab)Zeigt Semaphore- und Threadpool-basierte Begrenzung paralleler Aufrufe.
- Google SRE – Handling Overload (öffnet in neuem Tab)Zeigt Überlastschutz, Lastabweisung und die Begrenzung zusätzlicher Arbeit.