Backpressure und begrenzte Warteschlangen: die langsamste Stufe das Tempo vorgeben lassen

Worum es geht

Backpressure ist Flusskontrolle zwischen den Stufen einer Pipeline: Der Konsument signalisiert, wie viel er annehmen kann, und der Produzent wartet oder drosselt sich. Reactive Streams (zitiert) nennt als sein Ziel, den Austausch von Stream-Daten über eine asynchrone Grenze hinweg so zu steuern, dass die empfangende Seite nicht gezwungen ist, beliebig viele Daten zu puffern, wodurch die Warteschlangen zwischen Threads begrenzt bleiben können; in seinen Schnittstellen signalisiert der Subscriber Bedarf, indem er Elemente anfordert. In Node.js (zitiert) gibt writable.write() false zurück, sobald der interne Puffer highWaterMark erreicht, und das Ereignis 'drain' gibt an, wann das Schreiben fortgesetzt werden darf; stream.pipeline() verdrahtet dies zwischen den Stufen.

Das Google-SRE-Buch (zitiert) beschreibt die Variante für die Anfragebearbeitung: Die meisten Server nach dem Thread-pro-Anfrage-Prinzip halten eine Warteschlange vor einem Thread-Pool; ist die Warteschlange voll, weist der Server Anfragen zurück. Lange Warteschlangen erhöhen Latenz und Speicherverbrauch, und für einigermassen gleichmässigen Verkehr empfiehlt das Buch, die Warteschlangenlänge im Verhältnis zum Thread-Pool klein zu halten, damit der Server frühzeitig zurückweist, wenn er die eingehende Rate nicht bewältigen kann.

Warum es wichtig ist

Jeder unbegrenzte Puffer (eine In-Memory-Liste anstehender Jobs, ein unbegrenzter Channel, ein HTTP-Server, der ohne Grenze annimmt) verbirgt Überlast, bis dem Prozess der Speicher ausgeht oder seine Latenz jedes Client-Timeout überschreitet, worauf Clients es erneut versuchen und die Lage verschlimmern. Begrenzte Warteschlangen machen Überlast früh und sichtbar.

So wird es angewendet

• Jede Warteschlange begrenzen und bei Überfüllung eines von drei Verhalten wählen: den Produzenten blockieren (Backpressure), das neueste Element ablehnen (Shed), oder das älteste verwerfen (nur dort, wo frische Daten alte ersetzen).
• Das Signal bis an den Rand weiterleiten: Eine abgelehnte Anfrage wird zu einem HTTP 503 oder 429 mit Retry-After, nicht zu einem stillen Warten.
• In asynchronem Code begrenzte Channels oder Semaphoren um Aufrufe langsamerer Abhängigkeiten legen; in Stream-Code den Pipeline-Helfer der Plattform verwenden statt manueller on('data')-Handler.
• Warteschlangen nach akzeptabler Wartezeit bemessen: Warteschlangenlänge geteilt durch Durchsatz ist die zusätzliche Latenz bei Sättigung.
• Die Wartezeit in der Warteschlange (Alter des ältesten Elements) und die Anzahl der Ablehnungen messen; beide sind bessere Überlastsignale als CPU.

Stolpersteine

Einen Produzenten zu blockieren, der ein Lock oder eine Datenbankverbindung hält, kann das System in einen Deadlock führen. Timeouts ohne Ablehnung lassen die in der Warteschlange stehende Arbeit erledigen, nachdem der Client bereits gegangen ist. Eine Warteschlange vor einer Abhängigkeit, die selbst wartet, vervielfacht die Latenz. Wiederholungsversuche von vorgelagerter Seite müssen als Last mitgezählt werden.