مسئله: خزندهای بساز که میلیاردها صفحه را دانلود کند — موتور جستجوی گوگل (فصل ۸، cs8) با این شروع میشود. مسئله نه در «دانلود»، که در نظم، ادب و تکرار است.
۱-۲) نیازمندی و تخمین
- FR: شروع از seed ها، دنبالکردن لینکها، دانلود صفحات، استخراج لینک، خزش مجدد دورهای (تازگی).
- NFR: ادب (به هر هاست فشار محترمانه)، مقیاس میلیارد صفحه، تحمل خرابی، مقابله با تلههای خزنده (صفحه بینهایت، حلقه).
- تخمین: 1B صفحه در ۳۰ روز ≈ ~400 صفحه/ثانیه میانگین؛ با پیک و retry عملاً چند برابر — نیازمند صدها کارگر موازی.
- ذخیره: هر صفحه ~100KB فشرده × 1B ≈ صدها ترابایت — این یکی واقعاً مسئله storage است.
۳) طراحی — چرخه خزش
DIAGRAMپایپلاین خزنده
URL Frontier — صف اولویتدار
→
DNS Cache
→
Worker — دانلود
→
Parse + فیلتر تکرار
→
ذخیره — Blob
→
لینکهای تازه → Frontier
- URL Frontier قلب است: صف اولویتدار (صفحات مهم زودتر) + صف per-host برای ادب: به هر هاست حداکثر یک درخواست در چند ثانیه — politeness را تو enforce میکنی، نه robots.txt بهتنهایی (که آن هم رعایت میشود).
- حذف تکرار: آیا URL دیده شده؟ → Bloom Filter (فصل ۱۰) در حافظه + KV برای مطمئنشدن؛ آیا محتوا دیده شده؟ → هش/بردار شباهت صفحه — بدون این دو، میلیاردها دانلود هدر میرود.
- DNS به کندی مشهور است: کش DNS محلی در خزنده، صدها میلیثانیه هر درخواست را حذف میکند.
- تازگی: صفحات خبری ساعتی دوباره و آرشیوها سالیانه — اولویت بازخزش بر اساس نرخ تغییر تخمینزدهشده هر صفحه.
۴) عمق و گلوگاه
- تله: تقویم با بینهایت روز، لینکهای تولیدشده پویا — دفاع: محدودیت عمق، محدودیت URL per-domain، و تشخیص الگوی param.
- Render صفحات JS-محور: برای بخشی از وب به headless browser نیاز داری — صد برابر گرانتر؛ فقط برای دامنههایی که ارزشش را دارند.
- مقیاسدهی worker ها افقی است؛ گلوگاه واقعی پهنای باند و ادبِ per-host است، نه CPU.
به زبان ساده
خزنده وب یعنی یک صف اولویتدار عظیم (Frontier) که هم به هر سایت ادب دارد (نرخ محدود per سایت) هم با Bloom Filter از دانلود دوباره جلوگیری میکند.
مثال واقعی
مثل پیک مطالعاتی کتابخانه: برای هر ناشر (هاست) فقط هر چند دقیقه یک کتاب سفارش میدهد تا تحویلگیرنده ناشر خفه نشود، و دفترچهای دارد که میگوید این کتاب را قبلاً خواندهام.