Egy proxykészlet egy egyszerű kiesést elfoglalt ciklussá alakíthat. Válasszon címet, hibázzon, válasszon másikat, hibázzon újra. Ha minden végpont elérhetetlen, mert a saját hálózata esett ki, a címek váltogatása soha nem szünteti meg az okot.

Adjon a műveletnek keretet, mielőtt kiválasztja az első proxyt a készletből vagy az ingyenes proxy listáról: véges számú próbálkozás, korlátozott kapcsolódási és olvasási várakozás, valamint határidő a teljes feladatra. A Requests timeout a dokumentált kapcsolódási vagy olvasási viselkedését szabályozza; önmagában nem korlátoz egy ciklust, amely folyamatosan új kéréseket indít.

Döntse el, mi érdemel még egy próbálkozást

  • Egy elutasított proxykapcsolat indokolhatja egy másik végpont kipróbálását.
  • A cél válasza saját értelmezést kíván. HTTP-hiba fogadása bizonyítja, hogy valamelyik kérési útvonal befejeződött.
  • A proxy hitelesítési hiba a végpont és a fiók ellenőrzését kéri, nem pedig ugyanazon hitelesítő adatok verését egy növekvő listán.

Tartsa meg az eredeti kivételt vagy állapotot a próbálkozási rekorddal. Egy csak „minden proxy meghiúsult” szöveget tartalmazó záró üzenet elrejti, hogy a hibáknak egyáltalán ugyanaz volt-e az oka.

Minden proxy állapotellenőrzése minden valódi kérés előtt még egy kérést ad hozzá, és még így sem garantálja, hogy a következő sikerül. Használja újra a friss állapotadatokat ott, ahol illenek a feladathoz, és hagyja, hogy a valódi művelet jelentse a saját eredményét.

Az újrapróbálkozás megismételheti a munkát

Csak olvasó lekérésnél a másik proxyra váltás általában egyszerűbb, mint egy beküldés újrajátszása. Ha a kapcsolat egy vásárlás vagy űrlap elküldése után megszakad, előfordulhat, hogy a cél már feldolgozta. Kövesse a szolgáltatás idempotencia-mechanizmusát és a HTTP újrapróbálkozási szabályait, mielőtt megismétli a munkát.

Amikor a keret elfogy, adjon vissza hasznos hibát. A bizonyítékokkal leálló feladatot könnyebb kijavítani, mint azt, amely csendben forog, amíg valaki észre nem veszi.

Kapcsolódó cikkek