Xây dựng hệ thống Proxy Pool quét giá Shopee, Lazada không bị chặn

Kiến trúc 3 thành phần của một Proxy Pool chuyên nghiệp

Một hệ thống Proxy Pool cấp doanh nghiệp bao gồm 3 phân hệ cốt lõi hoạt động song song:

1. **Trình điều phối (Load Balancer & Dispatcher)**: Tiếp nhận request cào dữ liệu từ các worker và lựa chọn địa chỉ IP phù hợp nhất dựa trên đích đến (target domain), vị trí địa lý yêu cầu và lịch sử thành công của IP đó.

2. **Bộ giám sát sức khỏe (Health Check Worker)**: Liên tục gửi các truy vấn kiểm thử nhẹ (Heartbeat) tới các mục tiêu như Google, Shopee để đo lường độ trễ (latency) và tỷ lệ sạch của từng IP trong bể.

3. **Bộ chuyển mạch ngắt mạch (Circuit Breaker)**: Nếu một IP gặp liên tiếp 3 lỗi 403 (Forbidden) hoặc 429 (Too Many Requests), mạch sẽ lập tức "ngắt" (Open) và đẩy IP đó vào vùng cách ly trong 15 phút trước khi thử nghiệm lại.

Bảng đối chiếu thông số cào giá: Shopee vs Lazada vs TikTok Shop vs Amazon

Mỗi sàn thương mại điện tử có cơ chế giới hạn tần suất (Rate Limit) và rào cản phòng thủ riêng:

Case Study: Vận hành hạ tầng dữ liệu của Axio Coupon

Bạn có bao giờ tự hỏi làm thế nào tiện ích Axio Coupon có thể hiển thị biểu đồ lịch sử giá 180 ngày của bất kỳ sản phẩm nào trên Shopee và Lazada ngay khi người dùng mở trang web?

Đằng sau tính năng này là mạng lưới Axio Proxy Pool xử lý hơn 500 request mỗi giây. Hệ thống phân chia các luồng cào theo mức độ ưu tiên: các sản phẩm nằm trong Danh sách theo dõi giá (Watchlist) của người dùng được cập nhật mỗi 30 phút qua các đường truyền proxy dân cư ưu tiên cao, trong khi các sản phẩm phổ thông được cập nhật theo chu kỳ 12 giờ.

Nếu bạn đang phát triển các ứng dụng thương mại điện tử tương tự, bạn có thể tận dụng trực tiếp hạ tầng của chúng tôi qua các endpoint API tại AxioAPI Developer Hub.

Xử lý lỗi mạng và thuật toán Exponential Backoff với Jitter

Khi một sàn TMĐT bị quá tải hoặc phản hồi mã lỗi 429 (Too Many Requests), việc bot lập tức gửi lại request ngay sau 1 giây sẽ khiến IP bị chặn vĩnh viễn. Thay vào đó, áp dụng thuật toán Exponential Backoff với Jitter:

• Lần retry 1: Chờ 2 giây + ngẫu nhiên (0.1 - 0.5s).

• Lần retry 2: Chờ 4 giây + ngẫu nhiên.

• Lần retry 3: Chờ 8 giây, đổi sang một IP proxy mới hoàn toàn từ bể.

• Nếu sau 3 lần retry vẫn thất bại: Đánh dấu SKU sản phẩm vào hàng đợi ưu tiên thấp để cào lại vào ban đêm.

Chiến lược lưu bộ nhớ đệm (Cache) và tối ưu băng thông khi quét dữ liệu SKU lớn

Khi cào dữ liệu hàng trăm nghìn SKU trên Shopee hay Lazada, việc tải lại toàn bộ hình ảnh và tài nguyên tĩnh (CSS, JS) sẽ làm lãng phí 80% dung lượng băng thông proxy dân cư.

1. **Chặn tài nguyên không cần thiết**: Trong Puppeteer hoặc Playwright, luôn kích hoạt tính năng chặn tải hình ảnh (`image`), font chữ (`font`) và biểu định kiểu (`stylesheet`). Chỉ cho phép tải dữ liệu văn bản HTML và các request API dạng JSON.

2. **Lưu tạm mã băm ETag và Last-Modified**: Gửi kèm tiêu đề `If-None-Match` hoặc `If-Modified-Since`. Nếu trang sản phẩm không có thay đổi giá so với lần quét trước, máy chủ TMĐT sẽ trả về mã `304 Not Modified` chỉ tốn vài chục byte băng thông.

3. **Phân tầng tần suất quét**: Các sản phẩm bán chạy (Top Deals) quét 1 giờ/lần; các sản phẩm ít biến động giá chỉ cần quét 24 - 48 giờ/lần.

Quy chuẩn định danh User-Agent và phân bổ tải theo chu kỳ thời gian thực

Để tránh việc hệ thống WAF phát hiện các chu kỳ cào dữ liệu đều đặn bất thường, việc xáo trộn User-Agent và thời gian giữa các đợt request là bắt buộc:

• Duy trì một danh sách tối thiểu 500 chuỗi User-Agent đại diện cho các phiên bản Chrome, Safari và Edge mới nhất trên cả hệ điều hành Windows, macOS và iOS.

• Kết hợp ngẫu nhiên thời gian giãn cách (Jitter) từ 1.2 đến 3.8 giây giữa các lần tải trang để mô phỏng hoàn hảo hành vi duyệt web tự nhiên của con người.