Eine Proxy-Rotationsschleife stoppen, bevor sie ewig läuft
Gib einem Python-Proxy-Pool ein endliches Versuchsbudget und unterscheide Verbindungsfehler von Antworten des Ziels.
Ein Proxy-Pool kann aus einem einfachen Ausfall eine geschäftige Schleife machen. Adresse wählen, scheitern, andere wählen, wieder scheitern. Wenn jeder Endpunkt nicht erreichbar ist, weil das eigene Netz ausgefallen ist, behebt ein Adresswechsel nie die Ursache.
Gib dem Vorgang ein Budget, bevor du den ersten Proxy aus deinem Pool oder der Liste kostenloser Proxys wählst: eine endliche Anzahl von Versuchen, begrenzte Verbindungs- und Lese-Wartezeiten und eine Frist für die gesamte Aufgabe. Ein Requests-Timeout steuert das dokumentierte Verbindungs- oder Leseverhalten; es begrenzt nicht von sich aus eine Schleife, die immer neue Anfragen stellt.
Entscheide, was einen weiteren Versuch verdient
- Eine abgelehnte Proxy-Verbindung kann rechtfertigen, einen anderen Endpunkt zu versuchen.
- Eine Antwort des Ziels braucht ihre eigene Deutung. Eine HTTP-Fehlermeldung zu erhalten beweist, dass irgendein Anforderungspfad abgeschlossen wurde.
- Ein Proxy-Authentifizierungsfehler verlangt, Endpunkt und Konto zu prüfen, statt dieselben Zugangsdaten durch eine wachsende Liste zu hämmern.
Behalte die ursprüngliche Ausnahme oder den Status beim Versuchsdatensatz. Eine Abschlussmeldung mit nur „alle Proxys fehlgeschlagen“ verbirgt, ob die Fehler überhaupt dieselbe Ursache hatten.
Jeden Proxy vor jeder echten Anfrage auf Gesundheit zu prüfen, fügt eine weitere Anfrage hinzu und kann trotzdem nicht garantieren, dass die nächste gelingt. Verwende aktuelle Gesundheitsinformationen wieder, wo sie zur Aufgabe passen, und lass dann den echten Vorgang sein eigenes Ergebnis melden.
Ein erneuter Versuch kann die Arbeit wiederholen
Bei einem reinen Leseabruf ist der Wechsel zu einem anderen Proxy meist einfacher als das erneute Abspielen einer Übermittlung. Bricht eine Verbindung nach dem Senden eines Kaufs oder einer Formularübermittlung ab, hat das Ziel sie möglicherweise schon verarbeitet. Folge dem Idempotenzmechanismus des Dienstes und den HTTP-Wiederholungsregeln, bevor du Arbeit erneut abspielst.
Wenn das Budget erschöpft ist, gib einen brauchbaren Fehler zurück. Ein Job, der mit Belegen stoppt, ist leichter zu reparieren als einer, der still weiterrotiert, bis es jemandem auffällt.