Verteilung beginnt mit klaren Verantwortlichkeiten
Ein Prozess lässt sich technisch leicht auf mehrere Server kopieren. Schwierig wird die Frage, welcher Prozess welchen Auftrag besitzt, wie Doppelarbeit vermieden wird und was nach einem Abbruch geschieht. Ohne ein gemeinsames Zustandsmodell erzeugt horizontale Skalierung mehr Unklarheit statt mehr Zuverlässigkeit.
Eine robuste Architektur trennt Orchestrierung und Ausführung. Die zentrale Steuerung kennt Aufträge, Prioritäten und fachliche Zustände. Ausführende Prozesse reservieren begrenzte Arbeit, melden Fortschritt und liefern Ergebnisse. Sie dürfen ausfallen, ohne dass der Auftrag dauerhaft an ihre Maschine gebunden bleibt. Diese Trennung ermöglicht Crawling, Analyse und Rechecks mit jeweils passenden Ressourcen.
Zentrale Zustände und verteilte Ausführung bleiben über stabile Auftragskennungen verbunden.
Leases sind belastbarer als dauerhafter Besitz
Wenn ein Worker einen Auftrag abholt, erhält er eine zeitlich begrenzte Lease. Innerhalb dieser Frist gehört der Job diesem Prozess. Ein Heartbeat verlängert die Reservierung, solange der Worker tatsächlich arbeitet. Bleibt die Meldung aus, kann die Steuerung den Auftrag nach einer Sicherheitsfrist erneut freigeben.
Das Verfahren vermeidet Jobs, die nach einem Prozess- oder Serverausfall für immer als aktiv gelten. Gleichzeitig muss ein verspäteter alter Worker daran gehindert werden, ein neueres Ergebnis zu überschreiben. Eine Attempt-ID oder monotone Lease-Version begleitet deshalb jeden Schreibvorgang. Nur der aktuell berechtigte Versuch darf den Zustand bestätigen.
Crawler, Analyse und Recheck sind unterschiedliche Jobtypen
Crawling ist häufig netzwerkgebunden und muss Rate Limits, robotspezifische Regeln, Antwortcodes und Quellprioritäten berücksichtigen. Bild- oder Dokumentanalyse ist dagegen rechenintensiv. Ein Recheck prüft einen bekannten Status zu einem fachlich sinnvollen Zeitpunkt. Werden alle Typen in denselben Worker gepackt, konkurrieren sie um unpassende Ressourcen und erschweren die Fehleranalyse.
Getrennte Queues und Worker-Pools erlauben eigene Parallelität, Timeouts und Wiederholungsregeln. Das gemeinsame Datenmodell verbindet sie über die fachliche Entität und Korrelations-ID. Ein Crawler erzeugt Kandidaten, die Analyse ergänzt Signale, und eine nachgelagerte Statusprüfung aktualisiert das Ergebnis – ohne dass eine Komponente den gesamten Ablauf kennen muss.
Zustände müssen fachliche Übergänge abbilden
Ein boolesches Feld wie verarbeitet reicht in längeren Abläufen nicht aus. Sinnvoller ist ein explizites Zustandsmodell: geplant, reserviert, in Arbeit, technisch fehlgeschlagen, fachlich unklar, Ergebnis gespeichert, zur Prüfung bereit oder erneut zu kontrollieren. Erlaubte Übergänge werden zentral geprüft und mit Zeit, Attempt-ID und Ursache protokolliert.
So lässt sich beantworten, warum ein Vorgang wartet und welcher nächste Schritt zulässig ist. Fachliche Zustände dürfen nicht direkt aus der Existenz eines Prozesses abgeleitet werden. Ein Worker kann sauber beendet sein, obwohl sein Output unvollständig ist. Umgekehrt kann ein bereits gespeichertes Ergebnis gültig bleiben, wenn die abschließende Statusmeldung verloren ging.
Daten für einen nachvollziehbaren Auftrag
- Fachliche Job- und Korrelations-ID
- Jobtyp, Schema- und Verarbeitungs-version
- Priorität, Quelle und Erstellungszeit
- Lease-Inhaber, Attempt-ID und Heartbeat
- Ergebnisreferenz und Prüfsumme
- Fehlerklasse, nächster Versuch und Abschlussgrund
Zentrales Monitoring braucht technische und fachliche Sichten
Host-Monitoring zeigt CPU, Speicher, Plattenplatz und Prozesszustand. Pipeline-Monitoring ergänzt Queue-Länge, Jobalter, Laufzeiten, Wiederholungen und Durchsatz je Jobtyp. Die fachliche Sicht fragt außerdem, ob erwartete Ergebnisse entstehen, ob ein Quellbereich ungewöhnlich still ist und wie viele Vorgänge auf menschliche Entscheidung warten.
Dashboards und Alarme sollten eine konkrete Handlung auslösen. Ein voller Datenträger braucht eine andere Eskalation als ein wachsender Rückstand alter Rechecks. Alarmtexte enthalten betroffene Komponente, Umfang, erste Diagnose und verantwortlichen Weg. Ohne Runbook, Zuständigkeit und regelmäßig geprüften Empfang wird Monitoring schnell zu einer Sammlung ignorierter Meldungen.
Die technische Kette ist nur gesund, wenn am Ende erwartete fachliche Ergebnisse entstehen.
Rechecks modellieren Zeit als Teil des Prozesses
Viele Aufträge haben nach ihrer Ausführung noch kein endgültiges Ergebnis. Ein externer Dienst verarbeitet eine Meldung zeitversetzt, ein Import wird später bestätigt oder eine Ressource ändert ihren Status. Ein Recheck ist deshalb kein beliebiger Cronjob, sondern ein fachlich geplanter Folgeauftrag mit Bezug auf den ursprünglichen Vorgang.
Die nächste Prüfung wird aus Zustand, letzter Beobachtung und zulässigem Intervall berechnet. Wiederholte unveränderte Ergebnisse können den Abstand vergrößern; ein relevanter Zwischenstatus kann eine frühere Kontrolle auslösen. Gleichzeitig braucht es ein Ende: bestätigter Zielzustand, manuelle Entscheidung, fachliche Frist oder ausdrücklich dokumentierter Abbruch.
Praxisbezug: verteilte Verarbeitung ohne Blackbox
DMCA Protect verbindet spezialisierte Prozesse für Erfassung, visuelle Analyse und erneute Online-Prüfung mit einer zentral sichtbaren Ergebnissteuerung. Das Praxisbeispiel verdeutlicht, warum ein ausgeführter Auftrag und ein bestätigter fachlicher Ausgang verschiedene Zustände sind. Kunden- oder Quelldetails sind dafür nicht nötig; entscheidend ist das übertragbare Systemmuster.
In bestehenden PHP-Anwendungen kann die zentrale Geschäftslogik weiterhin PHP-basiert bleiben. Spezialisierte Dienste melden über versionierte APIs oder Queues zurück. Die Integration wird stabil, wenn Statusübergänge, Idempotenz und Betriebsmetriken gemeinsam geplant sind. Verteilung ist dann kein Selbstzweck, sondern eine kontrollierte Möglichkeit, unterschiedliche Arbeit zuverlässig auszuführen.