Redis là gì?

Scrapeless Agent Browser thực thi tự động hóa web công khai trong khi Redis có thể giữ trạng thái phối hợp riêng biệt cho ứng dụng bao quanh.

Redis là một máy chủ cấu trúc dữ liệu, thường được dùng cho cache, phối hợp và trạng thái ứng dụng hướng sự kiện. Ứng dụng truy cập giá trị thông qua các key và chọn cấu trúc phù hợp với các thao tác chúng cần. Giữ trạng thái được truy cập thường xuyên trong bộ nhớ có thể giảm khối lượng công việc cần thiết để phục vụ trạng thái đó, nhưng các chính sách lưu trữ bền vững và bộ nhớ của bản triển khai vẫn quyết định những gì có thể được giữ lại và khôi phục.

Một hệ thống thu thập có thể dùng Redis để nhớ các URL vừa truy cập, giữ công việc đang chờ, hoặc cache một kết quả đã được chấp nhận. Những vai trò đó có thời gian tồn tại khác nhau. Mất một trang được cache dùng một lần khác với mất bản ghi duy nhất của công việc chưa hoàn thành, nên cùng một chính sách triển khai Redis có thể không phù hợp cho mọi vai trò.

Key nhận diện giá trị với các cấu trúc khác nhau

Một key Redis nhận diện một giá trị mà kiểu dữ liệu của nó quyết định các thao tác sẵn có. String có thể giữ dãy byte, hash tổ chức các field, set biểu diễn các phần tử duy nhất, và sorted set gắn các phần tử với điểm số. List và stream hỗ trợ các mẫu tuần tự hoặc hướng sự kiện khác.

Mô hình cấu trúc dữ liệu Redis mang lại cho ứng dụng nhiều hơn một kho lưu trữ key-value không phân biệt. Việc chọn kiểu phù hợp có thể giữ cho thao tác gần với cấu trúc đã lưu trữ. Một set dùng cho kiểm tra thành viên trả lời một câu hỏi khác so với một sorted set dùng để sắp xếp thứ tự khối công việc đủ điều kiện.

Tên key nên thể hiện phạm vi. Một key URL-đã-truy-cập cho một nguồn và một giai đoạn thu thập không nên vô tình ngăn việc thu thập cho mọi giai đoạn tương lai. Hãy bao gồm các chiều phân biệt trạng thái ứng dụng, và ghi rõ phần nào của hệ thống sở hữu việc tạo và xóa nó.

Việc tuần tự hóa cũng cần một hợp đồng. Nếu một string giữ JSON, thì định dạng JSON xác định cú pháp hợp lệ nhưng không xác định schema hay phiên bản của payload. Bên tiêu thụ vẫn phải nhận diện được hình dạng bản ghi và từ chối các giá trị không tương thích thay vì coi mọi đối tượng đã giải mã là trạng thái ứng dụng hiện tại.

Cache lưu trữ các câu trả lời có thể tái sử dụng với một tuổi đời

Cache giữ lại một câu trả lời mà ứng dụng kỳ vọng sẽ tái sử dụng. Với dữ liệu web được thu thập, câu trả lời có thể là nội dung trang đã được chấp nhận hoặc một phản hồi đã được chuẩn hóa cho một ngữ cảnh nguồn cụ thể. Một lần cache hit chỉ tiết kiệm công việc thu thập khi câu trả lời đó vẫn còn phù hợp với yêu cầu mới.

Hãy xác định danh tính cache dựa trên mọi đầu vào liên quan. Một trang được thu thập ở một locale không nên đáp ứng một yêu cầu cho locale khác chỉ vì chuỗi URL trùng nhau. Tương tự, nội dung gắn với một tài khoản hoặc phiên nguồn cụ thể không nên được chia sẻ ra ngoài ngữ cảnh dự định.

Độ tươi của cache và độ tươi của quan sát có liên quan nhưng khác nhau. Một key vừa được tạo bây giờ có thể chứa một quan sát được thu thập từ trước. Lưu trữ ngữ cảnh quan sát cùng với giá trị được cache để bên tiêu thụ có thể đánh giá tuổi của nó. Kéo dài thời gian sống của key không tạo ra một quan sát mới về nguồn.

Hãy coi cache miss là một nhánh ứng dụng bình thường. Bộ thu thập cần biết cách lấy hoặc báo cáo việc không có câu trả lời có thể tái sử dụng mà không nhầm lẫn sự vắng mặt đó với việc nguồn đã bị xóa. Nếu không tồn tại kết quả mới được chấp nhận, giao diện có thể lộ ra một trạng thái không khả dụng rõ ràng thay vì tạo ra một giá trị.

Hết hạn và loại bỏ xóa key vì những lý do khác nhau

Hết hạn xóa một key theo thời gian sống được cấu hình của nó, trong khi loại bỏ xóa key theo một chính sách bộ nhớ. Thời gian sống ngắn thể hiện độ tươi hoặc thời gian lưu trữ được dự định. Một chính sách bộ nhớ thể hiện việc bản triển khai xử lý thế nào khi áp lực bộ nhớ chạm đến ngưỡng được cấu hình.

Một bài viết được cache thường có thể bị loại bỏ và thu thập lại. Một bản ghi phối hợp thiết lập quyền sở hữu công việc có thể cần được bảo vệ mạnh hơn. Nếu cả hai cùng chia sẻ một chính sách loại bỏ có thể xóa một trong hai, ứng dụng phải hiểu hệ quả trước khi coi bản ghi phối hợp là có tính quyết định.

Việc tính toán kích thước bộ nhớ bao gồm nhiều hơn độ dài nội dung thô. Key, value, cấu trúc nội bộ và các bộ đệm vận hành đều góp phần vào việc sử dụng tài nguyên. Hãy chọn phạm vi cache có giới hạn và quan sát bản triển khai thực tế thay vì ước lượng dung lượng chỉ từ kích thước của một payload đã tuần tự hóa.

Giữ cho các loại chẩn đoán tách biệt. Một kết quả được cache đã hết hạn, một kết quả bị loại bỏ và một kết quả chưa bao giờ được thu thập có thể đều trông giống như thiếu key ở biên đọc. Nếu sản phẩm cần phân biệt chúng, hãy ghi lại bằng chứng vòng đời cần thiết ở nơi khác hoặc thêm một giao thức ứng dụng rõ ràng quanh việc nạp cache.

Lưu trữ bền vững xác định kỳ vọng về khôi phục

Redis cung cấp các lựa chọn lưu trữ bền vững bao gồm snapshot tại một thời điểm và bản ghi chỉ-bổ-sung các thao tác ghi. Hành vi khôi phục của chúng phụ thuộc vào cấu hình và triển khai. Vì vậy, lưu trữ bền vững cần một điểm khôi phục chấp nhận được rõ ràng thay vì một khẳng định chung chung rằng trạng thái trong bộ nhớ không bao giờ có thể bị mất.

Đối với một cache dùng một lần, việc xây dựng lại từ tập dữ liệu đã được chấp nhận bên dưới có thể là đủ. Đối với một vành đai công việc, nhóm cần biết liệu các mục đang chờ có thể được tái tạo và liệu các mục đã hoàn thành có thể được nhận diện sau khi khôi phục hay không. Đó là các thuộc tính của ứng dụng, không phải hệ quả của việc chọn tên Redis.

Nhân bản và lưu trữ bền vững cũng có những vai trò khác nhau. Một bản sao đang chạy có thể hỗ trợ tính sẵn sàng, trong khi sao lưu lịch sử và khôi phục đã được kiểm thử giải quyết việc khôi phục khỏi các thay đổi không mong muốn. Một bản triển khai có thể có nhiều bản sao của một trạng thái sai, nên chỉ riêng tính sẵn sàng không thiết lập được khả năng khôi phục.

Trước khi sử dụng Redis như nơi duy nhất lưu trữ trạng thái quan trọng, hãy mô phỏng quy trình khôi phục với khối lượng công việc tiêu biểu. Kết quả phải cho thấy mục nào vẫn đang chờ xử lý, đầu ra nào đã được ghi nhận, và tuyên bố quyền sở hữu nào vẫn còn hiệu lực. Giữ bằng chứng khôi phục bên ngoài chính vùng trạng thái dễ mất mát mà nó nhằm giải thích.

Công Việc Trong Hàng Đợi Cần Quyền Sở Hữu và Hoàn Tất

Một hàng đợi ghi lại công việc cần được xử lý, trong khi giao thức ứng dụng quyết định khi nào việc xử lý được xem là hoàn tất. Việc xóa một mục khỏi vùng lưu trữ đang chờ không chứng minh được rằng đích đến đã chấp nhận đầu ra của nó. Một worker có thể dừng lại giữa các mốc đó.

Xác định danh tính công việc trước khi chọn các thao tác hàng đợi. Đối với một crawler tài liệu công khai, một mục công việc có thể xác định một trang chuẩn tắc và phạm vi bộ sưu tập. Tách biệt các giai đoạn khám phá, chấp nhận, quyền sở hữu đang hoạt động, và đầu ra đã hoàn tất để ứng dụng có thể hạch toán cho một trang trong suốt vòng đời của nó.

Một xác nhận cần tương ứng với một ranh giới hoàn tất có ý nghĩa. Nếu một worker xác nhận ngay sau khi tải xuống một trang, giai đoạn phân tích hoặc lưu trữ sau đó có thể lỗi mà không để lại một mục hàng đợi chưa hoàn thành. Hãy quyết định giai đoạn nào sở hữu việc hoàn tất và lưu trữ bằng chứng cần thiết để xác lập điều đó.

Ví dụ về một frontier crawler dùng Redis làm nền tảng cung cấp bối cảnh cho một frontier được xây dựng xoay quanh Redis. Hãy coi thiết kế hàng đợi là một phần của hợp đồng ứng dụng thay vì giả định rằng mọi danh sách URL đều là một hệ thống công việc bền vững. Thứ tự, loại bỏ trùng lặp, quyền sở hữu và đầu ra đã được chấp nhận là những quyết định riêng biệt.

Phối Hợp Công Việc Trình Duyệt Mà Không Trộn Lẫn Vòng Đời

Redis có thể phối hợp công việc xoay quanh một trình duyệt trong khi dịch vụ trình duyệt thực hiện việc chạy trang. Scrapeless Agent Browser cung cấp môi trường thực thi, và Scrapeless Agent Browser capabilities mô tả các khả năng của trình duyệt. Redis chỉ nên giữ thông tin điều phối mà ứng dụng cần, với thời gian tồn tại phù hợp với thông tin đó.

Một bản ghi công việc có thể xác định mục tiêu đã được phê duyệt và tác vụ ứng dụng mà không cần sao chép mọi thông tin xác thực trình duyệt vào trạng thái dùng chung. Giữ thông tin xác thực truy cập trong ranh giới được bảo vệ dự định của chúng và chỉ ghi log các định danh cần thiết cho chẩn đoán. Một hàng đợi không nên trở thành kho lưu trữ không giới hạn các bí mật phiên trình duyệt.

Nếu ứng dụng sử dụng token sở hữu cho một mục công việc, hãy làm rõ mục đích của nó. Các token đóng vai trò như bí mật cần có tính không thể đoán trước phù hợp; security randomness requirements giải thích tại sao các giá trị có thể đoán được là không phù hợp cho các mục đích nhạy cảm về bảo mật. Một nhãn lô dễ đọc với con người có vai trò khác và không nên được coi như một bí mật ủy quyền.

Quyền sở hữu cũng cần một quy tắc về hết hạn và worker lỗi thời. Một worker không còn sở hữu một tác vụ không nên có khả năng ghi đè một kết quả mới hơn đã được chấp nhận chỉ vì nó hoàn thành muộn hơn. Giao thức chấp nhận tại đích đến phải tính đến khả năng đó; một khóa tự hết hạn không thể tự mình thực thi mọi ranh giới ghi trong một hệ thống khác.

Chọn Redis Dựa Trên Thời Gian Sống Của Trạng Thái

Redis phù hợp với một vai trò khi cấu trúc dữ liệu và chính sách vận hành của nó đáp ứng nhu cầu truy cập và khôi phục cho vai trò đó. Một thiết kế hữu ích bắt đầu bằng việc phân loại giá trị nào có thể vứt bỏ và giá trị nào mô tả các nghĩa vụ chưa hoàn tất quan trọng.

Giữ khả năng và chi phí bên ngoài ở trạng thái dễ quan sát cùng nhau. Một frontier lớn hơn có thể làm tăng nhu cầu thu thập ngay cả khi bản thân Redis vẫn phản hồi tốt. Xem lại Scrapeless pricing cho công việc trình duyệt và giới hạn lượng công việc nguồn mà ứng dụng chấp nhận. Một kho điều phối nhanh nên giúp thực thi ranh giới đó thay vì cho phép một lượng tồn đọng khó giải thích tăng lên.

Kết luận

Redis cung cấp các cấu trúc dữ liệu cho truy cập nhanh vào trạng thái ứng dụng, nhưng mỗi vai trò cần hợp đồng vòng đời riêng. Xác định độ tươi của cache, danh tính công việc, quyền sở hữu và khôi phục trước khi chọn thiết lập hết hạn và lưu bền. Giữ đầu ra nghiệp vụ đã được chấp nhận trong một đích đến có độ bền phù hợp với tầm quan trọng của nó. Một thiết kế Redis hữu ích khiến cả một khóa bị thiếu và một mục công việc đã hoàn tất đều có thể được diễn giải.