Thảo luận về việc xây dựng hệ thống crawler

[tpphu]

Most features

• Design Database for two missions: (1) to store crawled info/data, (2) to monitor/analyze/alert if software does not not work normally.
• Design a crawler which is easy to scale
• Plugin/Extension/Add-on architect to attach new site quickly without downtime
• Avoid to be banned.

Database Design

Db có 2 yếu tố, 1 về nghiệp vụ Phú sẽ không bàn ở đây. Còn mình sẽ thiết kế để làm monitoring/analyzer/alert là chính, để biết hiện tại hệ thống đang xử lý những gì, đang bị lỗi ở domain nào, nguyên nhân gì v.v…

Software scaling

Để chạy với khả năng mở rộng cái cần là tư duy theo hướng gọi request, ajax và dùng json, html/jquery để parse thông tin. Nếu dùng browser như selenium, hay thậm chí headless browser như: https://github.com/GoogleChrome/puppeteer thì khả năng scale sẽ khó. Tuy nhiên các bạn có thể thử để có feeling.

Thậm chí chuẩn bị cả giải pháp về login.

Plugin architect

Mình sẽ thiết kế theo hướng generic để chỉ cần add thêm define của một domain khác là ready. Không phải code lại làm gì. Thậm chí có giao diện để vào cấu hình. Stop/Start bằng tool dashboard không cần phải restart hệ thống. Nếu muốn làm theo hướng này.

Dynamic and smart proxy usage

Proxy là phần khó nhất của hệ thống crawler, phải đảm bảo các yếu tố.

Chỉ có n request đến một domain trên 1 IP trong cùng một thời điểm. Chú ý là không phải request nào cũng có response giống nhau, nên phải tính theo thời gian trả về. Tránh DOS server. Trong một khoảng thời gian t chỉ gọi k request đến domain để không bj chặn. Theo rule của các ông system admin hay làm.

Vì mỗi IP tương đương với một VPS, và quan trọng nữa là có thể proxy sẽ phục vụ nhiều account (nếu mua loại này), thậm chí mỗi server chỉ có thể gởi một lượng request nhất định do VPS có cấu hình thấp như 1-2CPU, và 1-2G RAM. Nên do vậy, tổng số request trên cùng một VPS ở một thời điểm phải thiết kế giới hạn theo con số x nào đó. Nguyên nhân là do vấn đề lệ thuộc vào nhà cung cấp proxy. Công ty cũng không thể tự làm cái này. Bởi vì, rất khó linh hoạt trong việc đổi IP, và mua ở số lượng lớn. Phải đổi proxy dễ dàng, nếu vì code lỗi hay hư mà domain nó chặn cái IPs đó.

Nếu một request đến domain bị lỗi thì phải switch sang proxy khác, tức là cơ chế retry thông qua proxy.

[hiepndd]

Hi @tpphu Da, cai nay la crawl 1 url tu chon hay nhieu url cung 1 luc anh, cho em hoi la cai bai pre-assignment lan truoc em lam va bay gio van di theo huong do, anh @tpphu thay on khong?

[tpphu]

1. Về mặt lý thuyết thì việc dạy, anh không thể mở rộng bài tập thành một dự án với scope lớn thế này. Chúng ta chỉ trao đổi để cùng nhau hiểu rõ hơn vấn đề mà thôi.
2. Bài tập mà các bạn làm lần trước khá đơn giản. Chúng ta cần phải thiết kế lại cho ổn hơn chút, để làm sao đạt được nhiều hơn thì càng tốt.

[tpphu]

Như đã bàn trên lớp,

Chúng ta thiết kế bài tập này và các điều mà các bạn cần đạt được là:

1. Cần thiết kế chương trình để chia tách nghiệp vụ ra thành các gorountines hoạt động độc lập và sử dụng channels để trao đổi dữ liệu với nhau. Bài tập khuyến khích các bạn sử dụng: 1.1. DB để quản lý và cập nhật dữ liệu. 1.2. Khuyến khích các bạn nghĩ về hướng serverless theo nghĩa đơn giản là: chương trình có thể chạy được trên nhiều server độc lập. 1.3. Khuyến khích các bạn viết Unit Test càng nhiều càng tốt.
2. Phú đã thiết kế một pattern code đơn giản để các bạn có thể add vào bất kì một site nào theo mô hình đó mà chương trình có thể crawl được.