Xây dựng một Bộ thu thập thông tin Web Phân tán trong Node.js: Hàng đợi và Loại bỏ trùng lặp

Tóm tắt:

• Một trình thu thập web phân tán cần một biên URL bền vững, các công nhân không trạng thái, khóa URL chuẩn hóa, ngân sách yêu cầu cho mỗi máy chủ, và một con đường cách ly rõ ràng.
• Giữ Node.js chịu trách nhiệm cho việc khám phá, lập lịch, trạng thái và lưu trữ. Ủy thác việc xử lý JavaScript và thu thập trang cho một lớp thực thi được quản lý khi nguồn cần điều đó.
• Sử dụng băm URL chuẩn hóa làm cả ID công việc trong hàng đợi và khóa idempotency cho lưu trữ. Điều này ngăn chặn công việc trùng lặp trước khi nó đến tay một công nhân.
• Độ đồng thời của công nhân toàn cầu và kiểm soát nhịp độ theo máy chủ giải quyết các vấn đề khác nhau. Tăng quy mô cái đầu tiên theo dung lượng; đặt cái thứ hai từ quyền nguồn và hành vi máy chủ đã quan sát.
• Bắt đầu với một tập hợp nguồn ủy quyền nhỏ, đo lường các trang được chấp nhận thay vì các trang đã thử, và chỉ mở rộng sau khi độ sâu hàng đợi, độ trễ tươi mới, và sự từ chối lược đồ đã rõ ràng.

Một trình thu thập đơn quy trình thất bại theo những cách dễ đoán: hàng đợi bộ nhớ của nó biến mất khi khởi động lại, các liên kết trùng lặp nhân lên, một máy chủ chậm chiếm lĩnh vòng lặp sự kiện, và việc thực thi trình duyệt tiêu tốn cùng một máy mà lẽ ra nên lập lịch công việc.

Một trình thu thập web phân tán tách biệt những trách nhiệm đó. Node.js sở hữu mặt phẳng điều khiển—biên URL, trạng thái công việc, loại bỏ trùng lặp, và quyết định lưu trữ. Các công nhân độc lập sở hữu con đường dữ liệu. Đối với các trang công khai được render bằng JavaScript, một dịch vụ quản lý có thể thực hiện trang và trả về Markdown hoặc HTML mà không cần đặt các tiến trình trình duyệt bên trong mỗi container công nhân.

Xác định yêu cầu và chế độ thất bại

Trước khi chọn hàng đợi, viết hợp đồng thu thập:

• Các miền và đường dẫn nào được ủy quyền?
• Bao nhiêu trang và cấp độ có thể mỗi lần thu thập phát hiện?
• Cửa sổ độ tươi mới mà mỗi nguồn cần là gì?
• Các định dạng phản hồi nào và các trường bắt buộc nào xác định một trang được chấp nhận?
• Tốc độ yêu cầu nào được phép cho mỗi máy chủ?
• Kết quả không hợp lệ, trống hoặc không mong đợi sẽ đi đâu?
• Bao lâu thì các phiên bản công việc và trang phải được giữ lại?

Phiên bản đầu tiên cũng nên có các điều kiện dừng: độ sâu tối đa, số trang được chấp nhận tối đa, số URL phát hiện tối đa, và hạn chót. Những giới hạn này ngăn một kho lưu trữ lịch, điều hướng theo mặt phẳng, hoặc tham số theo dõi biến một lần thu thập nhỏ thành một cuộc đi bộ đồ thị không giới hạn.

Các chế độ thất bại thường gặp là kiến trúc:

Tách mặt phẳng điều khiển khỏi thực thi trang

Có thể vẽ trình thu thập thành hai mặt phẳng:

Mặt phẳng điều khiển: hạt giống → chuẩn hóa URL → loại bỏ trùng lặp → hàng đợi Redis → trạng thái công việc → siêu dữ liệu lưu trữ

Mặt phẳng thực thi: công nhân → thu thập trang → xác thực nội dung → trích xuất liên kết → ghi lại được chấp nhận hoặc cách ly

Ranh giới này quan trọng vì lập lịch và thực thi trình duyệt có quy mô khác nhau. Các hoạt động hàng đợi là nhỏ và có trạng thái. Thực thi trang nặng về mạng và có thể yêu cầu JavaScript, định tuyến khu vực, hoặc một phiên trình duyệt tách biệt.

Scrapeless Crawl hỗ trợ việc thu thập trang đơn, theo lô, và thu thập các liên kết với các định dạng bao gồm Markdown, HTML, liên kết, siêu dữ liệu và ảnh chụp màn hình. Khi con đường thực thi cần một trình duyệt tương tác, Scrapeless Scraping Browser giữ thời gian hoạt động bên ngoài container công nhân. Ứng dụng Node có thể giữ vai trò là hệ thống ghi cho phạm vi và trạng thái trong khi Scrapeless xử lý việc thu thập.

Để có một giới thiệu khái niệm về khám phá và trích xuất, đọc trình thu thập web là gì. Thiết kế dưới đây bắt đầu nơi một trình thu thập đơn máy dừng lại: hàng đợi được chia sẻ, xếp hàng idempotent, và nhiều công nhân.

Xây dựng biên URL hỗ trợ Redis

BullMQ thực hiện việc thực thi công việc phân tán trên Redis. Tài liệu chính thức của nó bao gồm hàng đợi, công nhân, sự kiện, công việc bị hoãn, giới hạn tần suất, và trạng thái công việc.

Biên nên lưu trữ một tải trọng công việc nhỏ:

Không đặt HTML trang vào Redis. Lưu kết quả lớn trong một kho đối tượng hoặc cơ sở dữ liệu và chỉ giữ lại các định danh, trạng thái và siêu dữ liệu gọn trong hàng đợi.

Sử dụng một hàng đợi riêng cho mỗi tên miền được chấp thuận khi các miền khác nhau yêu cầu ngân sách yêu cầu khác nhau. Các công nhân được phân công cho docs-example-com có thể sử dụng một bộ giới hạn, trong khi tên miền khác có thể nhận được nhịp điệu riêng. Một hàng đợi toàn cầu đơn giản hơn, nhưng bộ giới hạn của nó không thể diễn đạt các chính sách độc lập của các tên miền.

Đảm bảo việc thêm vào hàng đợi là idempotent

Hai trang có thể tương đương trong khi các URL thô của chúng khác nhau:

• một đoạn chỉ đến một vị trí bên trong cùng một tài liệu;
• các tham số theo dõi thay đổi mà không thay đổi nội dung;
• các tham số truy vấn xuất hiện theo thứ tự khác nhau;
• các cổng mặc định hoặc dấu gạch chéo cuối khác nhau;
• các liên kết tương đối giải quyết đến cùng một trang tuyệt đối.

Chuẩn hóa trước khi đưa vào hàng đợi. Tiêu chuẩn URL WHATWG định nghĩa mô hình phân tích được thực hiện bởi lớp URL của Node.js.

Một chính sách an toàn là cụ thể cho nguồn. Việc xóa mọi tham số truy vấn có thể kết hợp các trang thực sự khác nhau. Duy trì danh sách cho phép hoặc danh sách từ chối cho các tham số đã biết và giữ lại mọi tham số thay đổi tài nguyên.

Sau khi chuẩn hóa, băm URL với SHA-256. Sử dụng giá trị băm thập lục phân đó như:

• ID công việc BullMQ;
• khóa upsert cơ sở dữ liệu;
• liên kết nguồn gốc giữa công việc và trang đã lưu trữ.

BullMQ sẽ bỏ qua một công việc mới khi đã có một công việc khác với cùng ID tồn tại trong hàng đợi đó. Các bản ghi công việc bị loại bỏ do giữ lại không còn cung cấp mức bảo vệ đó, vì vậy lưu trữ bền cần giữ lại cùng một khóa idempotency.

Dự án Node.js phiên bản tối thiểu

Dự án này được thiết kế một cách có chủ đích rất gọn nhẹ:

distributed-crawler/
├── package.json
└── src/
    └── crawler.mjs

Các phiên bản phụ thuộc đã được kiểm tra so với các kho gói của chúng tại thời điểm soạn thảo. Ví dụ này là một khối khoảng trống về yêu cầu: nó yêu cầu Node.js, Redis, một SCRAPELESS_API_KEY, và một tên miền công cộng được ủy quyền được thiết lập trong ALLOWED_HOST. Nó được thiết kế cho một tên miền vì vậy bộ giới hạn hàng đợi thực sự là cụ thể cho tên miền đó.

{
  "name": "distributed-crawler-example",
  "private": true,
  "type": "module",
  "scripts": {
    "start": "node src/crawler.mjs"
  },
  "dependencies": {
    "@scrapeless-ai/sdk": "1.3.1",
    "bullmq": "5.79.3"
  },
  "engines": {
    "node": ">=22"
  }
}

Công nhân bên dưới có bốn kết quả cuối: accepted, unchanged, rejected, và quarantined. Nó không tạo ra một vòng lặp thất bại tự động. Một người điều hành có thể kiểm tra hồ sơ cách ly, khắc phục nguyên nhân, và rõ ràng đưa lại URL chuẩn vào hàng đợi.

import { createHash } from "node:crypto";
import { Queue, Worker } from "bullmq";
import { ScrapingCrawl } from "@scrapeless-ai/sdk";

const redis = {
  host: process.env.REDIS_HOST ?? "127.0.0.1",
  port: Number(process.env.REDIS_PORT ?? 6379)
};
const allowedHost = process.env.ALLOWED_HOST ?? "example.com";
const queueName = `crawl-${hostKey(allowedHost)}`;
const frontier = new Queue(queueName, { connection: redis });
const quarantine = new Queue(`${queueName}-quarantine`, { connection: redis });
const crawl = new ScrapingCrawl({
  apiKey: process.env.SCRAPELESS_API_KEY
});

function sha256(value) {
  return createHash("sha256").update(value).digest("hex");
}

function hostKey(host) {
  return host.toLowerCase().replaceAll(".", "-");
}

function canonicalize(input) {
  const url = new URL(input);
  url.hash = "";
  url.hostname = url.hostname.toLowerCase();
  for (const key of ["utm_source", "utm_medium", "utm_campaign"]) {
    url.searchParams.delete(key);
  }
  url.searchParams.sort();
  return url.href;
}

async function enqueue(url, crawlId, depth = 0, parentUrl = null) {
  const canonicalUrl = canonicalize(url);
  const parsed = new URL(canonicalUrl);
  if (parsed.hostname !== allowedHost) {
    throw new Error(`Host outside crawl scope: ${parsed.hostname}`);
  }

  const key = sha256(canonicalUrl);
  await frontier.add(
    "collect-page",
    {
      url: canonicalUrl,
      host: parsed.hostname,
      depth,
      crawlId,
      parentUrl,
      schemaVersion: "crawl-page-v1"
    },
    {
      jobId: key,
      removeOnComplete: 1000,
      removeOnFail: false
    }
  );
  return key;
}

const worker = new Worker(
  queueName,
  async (job) => {
    try {
      const result = await crawl.scrapeUrl(job.data.url, {
        formats: ["markdown", "links"],
        onlyMainContent: true,
        timeout: 15000
      });
      const markdown = result.markdown ?? result.data?.markdown;
      if (typeof markdown !== "string" || markdown.length < 200) {
        return { state: "rejected", reason: "content-contract", url: job.data.url };
      }

      const record = {
        key: job.id,
        url: job.data.url,
        crawlId: job.data.crawlId,
        depth: job.data.depth,
```plaintext
contentHash: sha256(markdown),
        markdown
      };

      console.log(JSON.stringify({ state: "accepted", ...record }));
      return { state: "accepted", key: record.key, contentHash: record.contentHash };
    } catch (error) {
      await quarantine.add("inspect-page", {
        ...job.data,
        sourceJobId: job.id,
        reason: error instanceof Error ? error.message : "unknown"
      });
      return { state: "quarantined", key: job.id };
    }
  },
  {
    connection: redis,
    concurrency: 4,
    limiter: { max: 2, duration: 1000 }
  }
);

worker.on("completed", (job, result) => {
  console.log(JSON.stringify({ event: "completed", jobId: job.id, result }));
});

worker.on("failed", (job, error) => {
  console.error(JSON.stringify({
    event: "worker-failed",
    jobId: job?.id,
    message: error.message
  }));
});

await enqueue(`https://${allowedHost}/`, "demo-crawl");

Ví dụ này in các bản ghi đã chấp nhận để làm cho hợp đồng dữ liệu có thể nhìn thấy. Thay thế `console.log` bằng cách upsert vào cơ sở dữ liệu được khóa bởi `record.key`. So sánh `contentHash` với giá trị đã lưu trước khi ghi một phiên bản trang mới hoặc xây dựng lại chỉ mục.

## Hiểu mô hình trạng thái nhiệm vụ

Một công cụ thu thập dữ liệu cần một mô hình trạng thái mà các nhà điều hành có thể giải thích:

| Trạng thái | Ý nghĩa | Hành động tiếp theo |
|---|---|---|
| `queued` | URL chính đang chờ | Công nhân chiếm lấy |
| `active` | Một công nhân sở hữu hợp đồng | Nhận và xác thực |
| `accepted` | Nội dung vượt qua hợp đồng | Lưu trữ, lập chỉ mục, phát hiện liên kết |
| `unchanged` | Băm nội dung khớp với phiên bản đã lưu | Cập nhật metadata độ mới |
| `rejected` | Phản hồi hoàn tất nhưng nội dung không hợp lệ | Xem xét bộ xác thực hoặc nguồn |
| `quarantined` | Thực thi không thể tạo ra quyết định | Kiểm tra và giải phóng bằng tay |
| `cancelled` | Phạm vi thu thập dữ liệu hoặc thời hạn đã kết thúc | Giữ lại metadata kiểm toán |

Giữ `failed` như một sự kiện hạ tầng được báo cáo bởi hàng đợi, không phải là trạng thái kinh doanh duy nhất. Một nhiệm vụ trả về một shell ứng dụng trống kỹ thuật là hoàn thành nhưng nên là `rejected`. Một trang nằm ngoài phạm vi nên được `cancelled` trước khi thu nhận. Những phân biệt này làm cho bảng điều khiển có thể hành động.

## Kiểm soát độ song song theo miền

Độ song song của công nhân trả lời: “Bao nhiêu nhiệm vụ mà quá trình này có thể xử lý?” Ngân sách yêu cầu của một máy chủ trả lời: “Bao nhiêu lưu lượng mà nguồn gốc này có thể nhận?” Chúng phải được cấu hình độc lập.

Đối với một miền được ủy quyền:

1. Đọc các quy tắc robot và giới hạn hợp đồng.
2. Đặt một tốc độ bảo thủ cho mỗi máy chủ.
3. Chạy nhiều công nhân chỉ khi hàng đợi và ngân sách máy chủ cho phép.
4. Theo dõi trạng thái phản hồi, sự chấp nhận nội dung và độ trễ máy chủ.
5. Giảm ngân sách máy chủ khi nguồn cho thấy căng thẳng hoặc thỏa thuận thay đổi.

Các công nhân BullMQ có thể chia sẻ một hàng đợi giữa các quá trình và máy móc. Bộ giới hạn hàng đợi điều phối hàng đợi đã chọn, đó là lý do tại sao ví dụ sử dụng một hàng đợi cụ thể cho máy chủ. Đối với nhiều miền, tạo hàng đợi từ một danh sách hồ sơ đã được chấp thuận và giới hạn số lượng các đối tượng công nhân hoạt động.

Giao thức loại trừ robot được chuẩn hóa bởi <a href="https://www.rfc-editor.org/rfc/rfc9309.html" rel="nofollow"><strong>RFC 9309</strong></a>. Các quy tắc robot không phải là sự cấp phép, và chúng không thay thế các điều khoản của trang web, nghĩa vụ bảo mật hoặc pháp luật hiện hành.

## Ủy quyền thu thập trang mà không mất quyền kiểm soát

Máy chủ điều khiển Node.js nên quyết định những gì có thể được thu thập. Lớp thực thi nên quyết định cách thu được đại diện trang được phép.

[Scrapeless Crawl quickstart](https://docs.scrapeless.com/en/crawl/quickstart/getting-started/?utm_source=website&utm_medium=blog&utm_campaign=crawl&utm_term=distributed-web-crawler-nodejs) tài liệu trạng thái thu thập dữ liệu bất đồng bộ và kết quả mức trang. Đối với các trang yêu cầu tương tác rộng hơn hoặc chạy JavaScript, hãy sử dụng tùy chọn trình duyệt của Crawl trong khi hàng đợi giữ phạm vi, danh tính nhiệm vụ và quyết định lưu trữ.

Xác thực nội dung trả về thay vì giả định bộ thực thi đã đưa ra quyết định kinh doanh. Yêu cầu văn bản, trường, ngôn ngữ, URL và nội dung tối thiểu được mong đợi. Lưu trữ lộ trình thu thập trong xuất xứ để một cuộc kiểm toán sau này có thể giải thích cách mỗi trang nhập vào tập dữ liệu.

## Khám phá liên kết mà không thoát khỏi phạm vi

Việc khám phá liên kết thuộc về sau khi chấp nhận nội dung. Phân tích chỉ các trang đáp ứng hợp đồng nội dung, sau đó áp dụng các bộ lọc này trước khi đưa vào hàng đợi:

- tên miền được cho phép;
- tiền tố đường dẫn được cho phép;
- các sơ đồ HTTP được hỗ trợ;
- độ sâu tối đa và số lượng trang;
- chuẩn hóa và tra cứu ID nhiệm vụ;
- loại file loại trừ;
- chính sách tham số truy vấn cụ thể nguồn.

Đừng để các chuyển hướng mở rộng âm thầm tập hợp các miền được cho phép. Ghi lại URL cuối cùng, so sánh nó với phạm vi, và từ chối các kết quả xuyên miền trừ khi danh sách nguồn rõ ràng cho phép chúng.

Đối với các sơ đồ trang web, hãy coi mỗi URL là đầu vào đã khám phá thay vì đầu ra đáng tin cậy. Chuẩn hóa, lọc và loại bỏ nó thông qua cùng một con đường biên giới như một liên kết HTML.

## Lưu trữ phiên bản trang và xuất xứ thu thập 

Một mô hình lưu trữ hữu ích có ba bản ghi:

1. Thu thập: phạm vi, URL hạt giống, thời hạn, phiên bản chính sách và trạng thái tổng thể.
2. Trang: khóa chuẩn, URL nguồn, băm mới nhất được chấp nhận, thời gian thu thập và phiên bản sơ đồ.
3. Phiên bản trang: băm nội dung, vị trí payload, siêu dữ liệu và gốc tiếp nhận.

Hàng đợi không phải là cơ sở dữ liệu lâu dài. Chính sách dọn dẹp công việc có thể loại bỏ các mục đã hoàn thành, trong khi bảng trang phải giữ lại các khóa idempotency và lịch sử phiên bản theo chính sách bảo quản.

Nếu một trang không thay đổi, hãy cập nhật dấu thời gian mới mà không nhân đôi payload. Nếu nó thay đổi, hãy ghi một phiên bản trang không thay đổi mới, trỏ bản ghi trang đến nó và thông báo cho việc lập chỉ mục ở phía dưới thông qua một sự kiện riêng.

Theo dõi quá trình thu thập

Độ dài hàng đợi chỉ có thể gây hiểu nhầm. Một trình thu thập có thể làm rỗng biên giới của nó trong khi từ chối mọi trang. Theo dõi:

OpenTelemetry mô tả các dấu vết, số liệu, nhật ký và hành lý trong hướng dẫn tín hiệu đo lường. Sử dụng một ID thu thập xuyên suốt giữa nhà sản xuất, sự kiện hàng đợi, cuộc gọi tiếp nhận, ghi lưu trữ và sự kiện chỉ mục xuống dòng.

Cảnh báo dữ liệu được chấp nhận cũ và mục cách ly cũ, không chỉ dựa trên sự cố quy trình. Một quy trình có thể khỏe mạnh trong khi tập dữ liệu dần dần không thay đổi.

Danh sách kiểm tra triển khai

• Chạy Redis với khả năng lưu trữ, xác thực, kiểm soát mạng và sao lưu phù hợp với khối lượng công việc.
• Giữ cho công nhân không trạng thái và triển khai cùng một hình ảnh trên các phiên bản.
• Lưu trữ khóa API trong quản lý bí mật hoặc tiêm môi trường, không bao giờ trong payload công việc.
• Định nghĩa việc bảo quản hàng đợi riêng biệt với việc bảo quản trang.
• Ràng buộc độ sâu thu thập, số trang, thời gian và phạm vi máy chủ.
• Sử dụng một nguồn chính sách máy chủ được chia sẻ bởi các nhà sản xuất và công nhân.
• Xả công nhân trong quá trình triển khai để các hợp đồng đang hoạt động không bị bỏ rơi.
• Kiểm tra việc hủy bỏ, giải phóng cách ly, tính idempotency lưu trữ và thay đổi chính sách nguồn.
• Ghi lại các phiên bản của Node.js, BullMQ, SDK Scrapeless và sơ đồ trang.

Bắt đầu với một máy chủ đã được phê duyệt và một giới hạn trang nhỏ. Chỉ thêm miền sau khi bảng điều khiển cho thấy rằng dữ liệu được chấp nhận, độ tươi và chính sách yêu cầu vẫn nằm trong mục tiêu của chúng.

Kết luận: mở rộng biên giới, không phải sự không chắc chắn

Một trình thu thập web phân tán trở nên đáng tin cậy khi mọi URL có một danh tính chuẩn, mọi máy chủ có một ngân sách rõ ràng và mọi trang kết thúc trong một trạng thái có ý nghĩa. Node.js và BullMQ có thể sở hữu biên giới và phối hợp công nhân; Scrapeless có thể sở hữu việc thực thi trang nơi cần quản lý kết xuất và xử lý mạng.

Tạo một bằng chứng khái niệm có giới hạn với một miền công khai, được ủy quyền, kiểm tra trang giá Scrapeless, sau đó tạo tài khoản Scrapeless. Chuyển tiếp việc tiếp nhận qua Thu thập và đo lường số trang được chấp nhận và độ tươi trước khi tăng số lượng công nhân.

Câu hỏi thường gặp

Điều gì làm cho một trình thu thập web phân tán?

Biên giới URL và trạng thái công việc của nó được chia sẻ qua nhiều quy trình hoặc máy chủ công nhân. Các công nhân có thể nhận công việc độc lập, ghi kết quả vào bộ lưu trữ chung và mở rộng mà không phụ thuộc vào bộ nhớ của một quy trình.

Tại sao sử dụng BullMQ cho một trình thu thập Node.js?

BullMQ cung cấp hàng đợi dựa trên Redis, công nhân phân tán, kiểm soát độ đồng thời, sự kiện và định danh công việc. Trình thu thập vẫn cần chính sách URL riêng, hợp đồng nội dung, lưu trữ bền vững và khả năng quan sát.

Làm thế nào việc loại bỏ URL hoạt động giữa các công nhân?

Chuẩn hóa URL trước khi đưa vào hàng đợi, băm định dạng chuẩn và sử dụng băm đó như ID công việc trong hàng đợi và khóa lưu trữ. Redis điều phối việc tạo công việc, trong khi cơ sở dữ liệu duy trì tính chất không đổi sau khi việc bảo quản hàng đợi loại bỏ các công việc cũ.

Liệu mỗi công nhân có cần khởi động trình duyệt riêng không?

Không nhất thiết. Trình duyệt cục bộ tăng kích thước container, mức sử dụng bộ nhớ và công việc vận hành. Một lớp tiếp nhận được quản lý có thể trả về nội dung đã kết xuất trong khi các công nhân vẫn tập trung vào lập lịch, kiểm tra, phát hiện và lưu trữ.

Nên xử lý các công việc trang thất bại như thế nào?

Tách biệt kết quả kinh doanh khỏi sự kiện hạ tầng. Nội dung không hợp lệ có thể bị từ chối; các lỗi thực thi chưa giải quyết có thể vào hàng đợi cách ly để kiểm tra và giải phóng rõ ràng. Tránh một vòng lặp tự động không giới hạn.