שימוש ב-SDK הסינכרוני ל-Python מתוך asyncio

הדוגמה דורשת Python 3.10+ ואת ה-SDK הרשמי של Python. הגדירו את SOLVETHREE_API_KEY ואת SOLVETHREE_PROXY בסביבת השרת שלכם. החליפו את accounts.example.com ואת login בשם המארח ובפעולה של היעד שלכם. לאתר כבר צריך להיות פרופיל פעיל שזמין לסביבת העבודה שלכם; ראו הגדרת פרופיל אתר.

import asyncio
import os
import uuid
from solvethree import Solvethree

async def main():
    limit = asyncio.Semaphore(4)
    async def solve_one(number):
        task = {"site": "accounts.example.com", "action": "login", "proxy": os.environ["SOLVETHREE_PROXY"], "requestId": str(uuid.uuid4())}
        def blocking_solve():
            return Solvethree(os.environ["SOLVETHREE_API_KEY"]).solve(task, timeout=180)
        async with limit:
            try:
                result = await asyncio.to_thread(blocking_solve)
                print("Ready task:", result["id"])
                # Submit the solution now with its proxy and browser identity.
            except Exception as error:
                print("Job", number, "requestId", task["requestId"], "error class", type(error).__name__)
                # Retain task and inspect SDK recovery IDs before restarting it.
    await asyncio.gather(*(solve_one(number) for number in range(8)))

asyncio.run(main())
# Canceling an await does not stop an already-running thread or remote task.

• הסמפור מאפשר לארבע עבודות להתבצע בכל פעם מתוך השמונה שנשלחו ל-gather. עבודות שממתינות למקום פנוי עדיין לא התחילו את קריאת ה-SDK שלהן.
• כל תהליכון עבודה יוצר לקוח Solvethree משלו במקום לשתף לקוח בין תהליכונים.
• ההגדרה timeout=180 של ה-SDK קובעת את הזמן המוקצב לפתרון. זמן ההמתנה לסמפור אינו נכלל בו. הגבלת זמן של asyncio סביב ה-await אינה תחליף לזמן המוקצב הזה ב-SDK.
• המשימה וה-requestId שלה נוצרים לפני הכניסה לתהליכון העבודה. שמרו את שניהם זמינים לשחזור במקום ליצור מזהה חלופי בכל פעם שמתרחשת שגיאה.

ה-SDK יוצר את המשימה פעם אחת ומתשאל עד שהיא מוכנה או עד שהוא מעלה שגיאה. אין צורך לכתוב לולאת תשאול נוספת סביב solve.

ביטול הקורוטינה שממתינה ל-to_thread אינו עוצר תהליכון שכבר פועל ואינו מבטל את פעולת הפתרון המרוחקת. מטפל החריגות הרגיל שבדוגמה אינו מבצע ניקוי בעקבות ביטול.

הדבר משפיע גם על מגבלת המקביליות: ביטול עלול לשחרר את הסמפור בזמן שתהליכון העבודה ממשיך לפעול. אם תאפשרו מיד לעבודות חלופיות להתחיל, יותר מארבע קריאות SDK עלולות להישאר פעילות. אם נדרשת מגבלה קשיחה במהלך ביטול, עקבו אחר תהליכוני עבודה שטרם הסתיימו והשאירו את הקיבולת שלהם תפוסה עד שיסיימו.

לשימוש בסביבת ייצור, שמרו את הקלטים המדויקים של המשימה ואת מזהה הבקשה במקום שמנגנון השחזור יוכל לגשת אליו לאחר יציאת הקורוטינה. חריגה מהזמן הקצוב פירושה שהפסקתם לקבל תוצאה, לא בהכרח שיצירת המשימה נכשלה.

1. 1.

   שחזור משימה ידועה

   בדקו את task_id ואת request_id בשגיאת ה-SDK של Python. אם יש לכם מזהה משימה, המשיכו בשליפה באמצעות get_task במקום ליצור משימה נוספת.

2. 2.

   שחזור יצירה שנקטעה

   אם אין לכם מזהה משימה, שלחו שוב קלטים זהים של המשימה עם ה-requestId המקורי. כך תוחזר המשימה הקיימת אם היצירה הצליחה. שינוי הקלטים תוך שימוש חוזר באותו מזהה גורם להתנגשות.

3. 3.

   הבחנה בין כשל להפרעה בתהליך

   TaskFailedError מציין שהמשימה הגיעה לסטטוס סופי של כישלון. בדקו את errorCode ואת error שלה; אל תמשיכו לתשאל אותה ואל תנסו שוב באופן עיוור עם קלטים לא תקינים שלא שונו. שגיאות HTTP הן שכבת כשל נפרדת.

הדוגמה מדפיסה את מזהה המשימה המוכנה; היא אינה שולחת דבר ליעד. החליפו את ההערה שאחרי ההדפסה בשליחה המתאימה ליישום שלכם, והשתמשו בפתרון בהקדם במקום להמתין לסיום כל העבודות ב-gather.

שלחו את הפתרון שהוחזר עם ה-userAgent וה-secChUa שלו, ובאמצעות אותו פרוקסי ששימש לפתרון. פונקציית העזר successful_proxy של ה-SDK בוחרת את הפרוקסי מתוך המשימה המקורית והתוצאה המוכנה. תוצאה מוכנה פירושה שנוצר פתרון — לא שבקשת היישום שלכם הצליחה.