Seite 52 - Mironsoft Blog

Wenn eine externe API langsam antwortet oder komplett ausfällt, wartet jeder aufrufende Request in einer typischen PHP-Anwendung brav auf sein Timeout, während sich im Hintergrund PHP-FPM-Worker stauen und die eigene Anwendung mit in den Abgrund reißen. Das Circuit-Breaker-Pattern durchbricht diese Kette, indem es nach einer bestimmten Anzahl von Fehlern den Stromkreis unterbricht und weitere Aufrufe sofort mit einem Fallback beantwortet, statt sie erneut ins Leere laufen zu lassen.

Ein Offsite Backup ist die Kopie, die einen Brand, Diebstahl oder eine Ransomware-Infektion des lokalen Standorts uebersteht. Die 3-2-1-Regel gibt dafuer eine einfache, aber wirksame Formel vor: drei Kopien der Daten, auf zwei verschiedenen Medienarten, davon eine physisch getrennt vom Hauptstandort. Dieser Artikel zeigt, wie sich diese Regel auf Linux-Servern automatisiert, verschluesselt und ueberwacht umsetzen laesst.

Cache beschleunigt Builds durch Wiederverwendung von Downloadergebnissen. Artefakte übertragen gebaute Resultate zwischen Jobs. Wer beide verwechselt, kämpft mit inkonsistenten Builds, unnötig langen Pipeline-Laufzeiten und schwer reproduzierbaren Deployment-Artefakten für Magento.

Wer in einer Schleife tausendfach ein externes Kommando neu startet, verschenkt Laufzeit durch wiederholten Prozessstart. Ein Coprozess hält genau ein solches Kommando dauerhaft im Hintergrund am Leben und erlaubt der Shell, über zwei Filedeskriptoren in beide Richtungen mit ihm zu sprechen, statt für jede einzelne Anfrage einen neuen Kindprozess zu erzeugen.

Statische Tests decken in Magento 2 genau die Fehlerklasse auf, die weder PHPStan noch PHPUnit sehen: Verstöße gegen den Magento Coding Standard, undeklarierte Abhängigkeiten zwischen Modulen und schleichend wieder eingeschleppte Legacy-Patterns. Wer die eigene Suite unter dev/tests/static ernst nimmt, verhindert genau die Art von strukturellen Fehlern, die erst beim nächsten Major-Update oder bei einer geänderten Modul-Ladereihenfolge sichtbar werden.

Doctrine ORM bietet zwei grundlegend verschiedene Wege, auf Datenbankoperationen zu reagieren: Lifecycle Callbacks direkt in der Entity und Doctrine Event Listeners als eigenständige Services. Beide lösen dasselbe Problem, aber mit unterschiedlicher Architektur, Testbarkeit und Abhängigkeitsverwaltung.

Sorted Sets gelten meist als Werkzeug fuer Leaderboards, sind aber eine der vielseitigsten Datenstrukturen in Redis. Mit einer nach Score sortierten Skip List im Hintergrund eignen sich Sorted Sets ebenso fuer Zeitreihen, verzoegerte Job-Ausfuehrung und Prioritaets-Warteschlangen, oft ohne zusaetzliche Infrastruktur neben Redis selbst.

Bash bringt mit der Pseudo-Datei /dev/tcp ein eingebautes Werkzeug mit, um zu prüfen, ob ein TCP-Port auf einem anderen Host erreichbar ist, ganz ohne netcat, nmap oder ein Zusatzpaket zu installieren. Für einfache Erreichbarkeits-Checks in Monitoring- und Deployment-Skripten reicht das oft völlig aus, für echte Sicherheitsanalysen oder große Netzbereiche ist es dagegen der falsche Werkzeugkasten.

Jede Form von Persistence in Redis kostet Latenz, ob durch fsync-Aufrufe bei jedem Schreibvorgang oder durch den Fork-Prozess hinter einem Snapshot. Wer diesen Tradeoff nicht versteht, wählt entweder eine Konfiguration, die Latenzspitzen im Produktivbetrieb verursacht, oder eine, die im Ernstfall mehr Daten verliert als geplant.

Sobald eine Transaktion mehrere unabhängige Datenbanken oder Services betrifft, reicht ein einfaches COMMIT nicht mehr aus, um Atomarität zu garantieren. Two-Phase Commit löst dieses Problem über ein Koordinator-basiertes Prepare-und-Commit-Protokoll, hat aber strukturelle Schwächen, die in großen, verteilten Systemen heute meist den Saga Pattern-Ansatz mit kompensierenden Aktionen bevorzugen lassen.