پروکسی و Rate Limit در کرالر؛ پایداری بدون فشار به منبع

پروکسی و Rate Limit در کرالر برای این نیست که هر محدودیتی را دور بزنیم؛ برای این است که کرالر با سرعت قابل‌پیش‌بینی، فشار کنترل‌شده و امکان توقف کار کند. وقتی یک منبع عمومی را بیش از ظرفیتش درخواست می‌زنید، هم کیفیت داده پایین می‌آید و هم احتمال خطا، timeout و قطع دسترسی بالا می‌رود. معماری پایدار از احترام به منبع، صف، retry محدود و مانیتورینگ شروع می‌شود.

جست‌وجوهایی مثل «چرا کرالر بلاک می‌شود»، «Rate Limit چیست»، «پروکسی چرخشی برای اسکرپ»، «چطور کرالر را پایدار کنیم» و «مدیریت خطای 429» معمولاً از تیمی می‌آید که نسخه اولیه استخراج را ساخته اما اجرای روزانه‌اش ناپایدار شده است. این راهنما روی پایداری و کنترل بار تمرکز دارد؛ تعریف کلی وب اسکرپینگ در راهنمای اسکرپ دیتا و انتخاب روش مرورگر در اسکرپ با Playwright آمده است. اجرای پروژه باید در چارچوب منبع مجاز و شرایط استفاده آن باشد، نه با دورزدن قفل.

A 429 status code indicates that the user has sent too many requests in a given amount of time.

Rate Limit در کرالر یعنی چه؟

Rate Limit سقفی برای تعداد درخواست در یک بازه است؛ این سقف ممکن است از سمت سرویس مقصد، API رسمی، شبکه یا حتی زیرساخت خود شما اعمال شود. پاسخ 429 یک علامت مهم است: فرستادن درخواست بیشتر معمولاً مشکل را حل نمی‌کند. باید Retry-After یا سیاست اعلام‌شده را بخوانید، زمان انتظار را افزایش دهید و اگر خطا ادامه داشت، صف را متوقف یا کوچک کنید.

محدودکننده را فقط روی کل پروژه نگذارید. یک منبع ممکن است برای مسیر جست‌وجو، تصویر و API رفتار متفاوت داشته باشد. نرخ درخواست، هم‌زمانی، timeout و اندازه صفحه را جداگانه ثبت کنید. اگر منبع API رسمی دارد، قرارداد همان API بر حدس‌زدن سرعت با اسکرپر مقدم است؛ مقایسهٔ این دو روش را در تفاوت اسکرپ و API بخوانید.

Backoff و Retry را چطور طراحی کنیم؟

Retry یعنی تلاش دوباره برای خطای موقت، نه تکرار بی‌پایان. برای خطاهای شبکه و 429 می‌توان از backoff افزایشی استفاده کرد: فاصلهٔ تلاش دوم بیشتر از اول باشد و کمی jitter اضافه شود تا همهٔ workerها هم‌زمان دوباره درخواست نزنند. تعداد تلاش، سقف انتظار و خطاهای قابل‌تلاش باید در تنظیمات پروژه ثبت شود.

برای 404 یا خطای اعتبارسنجی داده معمولاً retry فایده ندارد. این خطاها را در صف خطا قرار دهید تا تیم ببیند. پاسخ 500 ممکن است موقت باشد، اما اگر برای یک URL بارها تکرار شد، آن URL را قرنطینه کنید. در هر تلاش شناسهٔ job، URL نرمال‌شده، زمان، status و علت توقف را لاگ کنید؛ لاگ بدون شناسه در مقیاس واقعی قابل‌استفاده نیست.

پروکسی چه مشکلی را حل می‌کند؟

پروکسی مسیر خروجی درخواست را تغییر می‌دهد و در بعضی معماری‌های قانونی برای جداسازی شبکه، منطقهٔ جغرافیایی یا کنترل خروجی سازمان به کار می‌رود. پروکسی، مجوز دسترسی ایجاد نمی‌کند و جایگزین Rate Limit، شرایط استفاده یا API رسمی نیست. اگر منبع برداشت خودکار را ممنوع کرده باشد، چرخاندن IP پاسخ مسئولانه‌ای به آن ممنوعیت نیست.

در پروژه‌های مجاز، کیفیت پروکسی از تعداد آن مهم‌تر است. باید latency، خطای اتصال، منطقه، زمان انقضا و هزینهٔ هر مسیر ثبت شود. پروکسی خراب باعث می‌شود مشکل منبع را با مشکل شبکه اشتباه بگیرید. برای منبعی که به IP ثابت نیاز دارد، چرخش بی‌دلیل حتی می‌تواند کیفیت و قابلیت ردیابی را بدتر کند.

پروکسی را در یک لایهٔ قابل‌تعویض قرار دهید، نه در منطق استخراج فیلد. Worker باید بتواند از مسیر مجاز درخواست بفرستد و در صورت خرابی، job را متوقف کند. اطلاعات احراز هویت پروکسی را در کد و لاگ ننویسید. این مرزبندی همان چیزی است که نگهداری کرالر را از مجموعه‌ای از اسکریپت‌های شکننده جدا می‌کند.

هم‌زمانی و صف را چطور تنظیم کنیم؟

هم‌زمانی تعداد درخواست‌هایی است که در یک لحظه در جریان‌اند. افزایش آن همیشه throughput را بالا نمی‌برد؛ ممکن است CPU، حافظه، connection pool یا سرویس مقصد را پر کند. از یک مقدار پایین شروع کنید، زمان پاسخ و نرخ خطا را اندازه بگیرید و فقط وقتی افزایش دهید که دادهٔ سالم و فشار قابل‌قبول دارید.

صف پیام باید وضعیت job را بداند: pending، running، success، retry و failed. در صورت قطع worker، job نباید برای همیشه running بماند؛ lease یا timeout اجرای آن را دوباره قابل‌بررسی می‌کند. خروجی موقت را ذخیره کنید تا retry مجبور نباشد تمام مسیر را از اول انجام دهد. برای دادهٔ نهایی و حذف تکرار، راهنمای پاک‌سازی داده اسکرپ را کنار این طراحی قرار دهید.

چه چیزهایی را باید مانیتور کنیم؟

حداقل داشبورد کرالر باید تعداد URLهای موفق، شکست‌خورده، در صف، retry‌شده و متوقف‌شده را نشان دهد. نرخ 429، timeout، 403، میانگین زمان پاسخ و حجم خروجی را بر اساس منبع جدا کنید. یک نرخ موفقیت کلی ممکن است خطای یک منبع مهم را پنهان کند؛ breakdown به تفکیک domain و نوع job ضروری است.

هشدار را برای هر نوسان کوچک فعال نکنید. آستانهٔ مهم تعریف کنید: افزایش ناگهانی 429، صفر شدن خروجی، افت شدید رکورد معتبر یا رشد صف بدون مصرف. هشدار باید اقدام بعدی را هم بگوید: توقف worker، کاهش concurrency، بررسی منبع یا بازبینی selector. مانیتورینگ برای این است که قبل از گزارش اشتباه به تیم محصول متوجه مشکل شوید.

مرز اجرایی و مسئولانه کجاست؟

قبل از اجرا robots.txt، شرایط استفاده، API رسمی و نوع داده را بررسی کنید. دادهٔ عمومی به معنی مجوز نامحدود برای برداشت نیست و پروکسی به معنی عبور از محدودیت نیست. حساب کاربری، دادهٔ خصوصی و CAPTCHA را وارد محدوده‌ای نکنید که مجوز روشن ندارد. جزئیات این تصمیم را در مستندات پروژه بنویسید تا بعداً کسی با تغییر یک تنظیم، رفتار پرریسک نسازد.

اشتباهات رایج پایداری کرالر

• افزایش هم‌زمانی برای جبران selector یا کد استخراج ضعیف
• Retry بی‌نهایت برای پاسخ 404 یا دادهٔ نامعتبر
• چرخش پروکسی بدون ثبت مسیر و هزینه
• ثبت نکردن Retry-After و بی‌توجهی به 429
• ارسال چند worker بدون هماهنگی روی یک منبع
• حذف لاگ خام و ناتوانی در بازسازی علت خطا
• استفاده از پروکسی برای دور زدن ممنوعیت منبع

چک‌لیست کرالر پایدار

1. منبع، مجوز و نوع دادهٔ مجاز مستند شده است.
2. Rate Limit و سقف هم‌زمانی برای هر منبع مشخص است.
3. Retry فقط برای خطاهای موقت و با سقف اجرا می‌شود.
4. Backoff و jitter از هم‌زمانی دوبارهٔ workerها جلوگیری می‌کند.
5. صف وضعیت job و timeout اجرای آن را ثبت می‌کند.
6. پروکسی لایه‌ای جدا، قابل‌تعویض و قابل‌مانیتور است.
7. 429، timeout، 403 و افت داده هشدار مناسب دارند.
8. خروجی با نمونهٔ منبع تطبیق و نسخهٔ خام حفظ می‌شود.

جمع‌بندی: پایداری از کنترل شروع می‌شود

کرالر پایدار سریع‌ترین کرالر ممکن نیست؛ کرالری است که با نرخ مشخص، خطای قابل‌پیگیری، صف قابل‌توقف و دادهٔ قابل‌اعتماد اجرا می‌شود. پروکسی فقط یکی از اجزاست و هرگز مجوز دسترسی یا جایگزین API نیست. اول منبع و قرارداد را روشن کنید، بعد Rate Limit، صف، retry و مانیتورینگ را طراحی کنید.

اگر برای منبع مجاز خود به کرالر، پاک‌سازی داده و خروجی API نیاز دارید، خدمات اسکرپ دیتا و کرالر روبینش را ببینید یا از فرم تماس شروع کنید. پروژه باید با نمونهٔ واقعی منبع و محدودهٔ روشن برآورد شود، نه با وعدهٔ دور زدن محدودیت.