Bộ giới hạn tần suất là gì? Thuật toán, ngân sách và phạm vi

Scrapeless Web Unlocker xử lý việc truy xuất nội dung dựa trên URL trong khi ứng dụng của bạn có thể đặt một bộ giới hạn tần suất xung quanh các yêu cầu mà nó chấp nhận.

Bộ giới hạn tần suất kiểm soát việc cho phép thực hiện một thao tác

Bộ giới hạn tần suất là một thành phần quyết định liệu một thao tác có thể tiếp tục theo một chính sách về hoạt động theo thời gian hay không. Nó có thể nằm ở phía client trước khi gửi yêu cầu, tại API gateway, hoặc bên trong ứng dụng gần một thao tác tốn kém. Thành phần này quan sát trạng thái liên quan và đưa ra quyết định cho phép, trong khi chính sách định nghĩa đếm cái gì và cho đối tượng nào.

Một chính sách hữu ích nêu rõ đối tượng, thao tác, đơn vị đếm, mô hình thời gian và hành động khi cạn mức. Ví dụ, một dịch vụ xuất giả định có thể phân bổ một hạn mức cho mỗi tenant đối với số lần bắt đầu xuất và một giới hạn khác cho số phiên xuất đang hoạt động. Đây là một thiết kế minh họa, không phải là hạn ngạch của Scrapeless. Thiếu các chi tiết đó, một phát biểu như số yêu cầu mỗi phút có thể che giấu hành vi quan trọng nhất khi hệ thống chịu tải.

Định nghĩa HTTP 429 cung cấp cho các dịch vụ HTTP một mã trạng thái cho hoạt động yêu cầu quá mức, nhưng mã trạng thái này không quy định một thuật toán giới hạn tần suất mang tính phổ quát. Máy chủ có thể nhận diện bên gọi và đếm thao tác theo chính sách riêng của nó. Một client quan sát 429 không thể suy luận dịch vụ có dùng cửa sổ cố định, token bucket hay một ngân sách tài nguyên phức tạp hơn hay không.

Phạm vi quyết định ai chia sẻ hạn mức

Phạm vi của bộ giới hạn xác định những yêu cầu nào cạnh tranh cùng một dung lượng. Một dịch vụ có thể đếm hoạt động theo tài khoản, tenant, khóa API, người dùng, route, địa chỉ IP hoặc một khóa tổng hợp. Một chính sách dựa trên IP có thể gom các người dùng không liên quan đứng sau cùng một mạng chia sẻ, trong khi một chính sách dựa trên tài khoản có thể gộp lưu lượng từ nhiều tiến trình khác nhau. Hãy chọn phạm vi để phù hợp với ranh giới tài nguyên hoặc công bằng mà dịch vụ cần bảo vệ.

Các chính sách phân cấp có thể được áp dụng đồng thời. Một yêu cầu có thể cần dung lượng dưới hạn mức của tenant, hạn mức của endpoint và trần toàn dịch vụ. Hệ thống cho phép phải định nghĩa cách các kiểm tra này tương tác và cách công việc được chấp nhận được hạch toán. Một tập hợp lỏng lẻo các kiểm tra độc lập có thể tạo ra khấu trừ không nhất quán hoặc cho phép công việc đi qua sau khi một ràng buộc khác lẽ ra phải chặn lại.

Các ứng dụng phía client cũng cần nhận thức về phạm vi như vậy. Nếu nhiều collector dùng chung một tài khoản của nhà cung cấp, các quyết định gửi yêu cầu của chúng nên chia sẻ hạn mức của tài khoản thay vì mỗi bên tự nhận toàn bộ hạn mức. Một bộ giới hạn cục bộ vẫn có thể bảo vệ một tiến trình, nhưng nó không nên được mô tả như một chính sách toàn cục chính xác trừ khi cơ chế phối hợp của nó bao phủ mọi bên tiêu thụ liên quan.

Cửa sổ cố định và cửa sổ trượt đếm thời gian theo cách khác nhau

Một bộ giới hạn cửa sổ cố định đếm các thao tác được chấp nhận trong các khoảng thời gian được đặt tên và đặt lại bộ đếm tại ranh giới. Cách tiếp cận này dễ mô tả và có thể rẻ để vận hành. Hành vi tại ranh giới rất quan trọng: một client có thể dùng hết hạn mức của một khoảng thời gian gần cuối khoảng đó và ngay sau đó dùng luôn hạn mức của khoảng kế tiếp. Vì vậy, một mức trung bình thấp qua các khoảng riêng rẽ vẫn có thể bao gồm một đợt burst tập trung.

Một bộ giới hạn cửa sổ trượt dựa trên log giữ timestamp cho hoạt động trong một khoảng di động và đánh giá trực tiếp cửa sổ hiện tại. Nó có thể mô tả một chính sách cuộn chặt chẽ hơn, nhưng việc lưu timestamp cho từng thao tác có chi phí trạng thái. Một bộ đếm cửa sổ trượt xấp xỉ hành vi đó bằng các bộ đếm tổng hợp. Độ chính xác và hành vi tại ranh giới của nó phụ thuộc vào thuật toán được chọn, nên hãy ghi rõ liệu chính sách là chính xác hay xấp xỉ.

Hãy dùng lưu lượng tổng hợp tại các ranh giới khoảng thời gian khi thử nghiệm những thiết kế này. Một khối lượng công việc ổn định có thể không bao giờ bộc lộ một đợt burst ở ranh giới hoặc một bất nhất liên quan đến đồng hồ. Hãy định nghĩa số lần cho phép mong đợi trước khi chạy thử nghiệm, sau đó so sánh các thao tác được chấp nhận với chính sách thay vì chỉ đếm phản hồi lỗi. Tính đúng đắn của bộ giới hạn là một thuộc tính của lịch sử quyết định của nó dưới mô hình đã nêu.

Token bucket tách tốc độ duy trì khỏi dung lượng burst

Một token bucket duy trì một hạn mức được làm đầy theo thời gian cho đến một dung lượng tối đa. Một thao tác được chấp nhận sẽ tiêu thụ token theo chi phí được gán cho nó. Tốc độ nạp lại mô tả mức hoạt động bền vững, trong khi dung lượng bucket mô tả lượng hạn mức tích lũy có thể tiêu trong một đợt burst. Đây là những thiết lập riêng biệt và nên được giải thích riêng cho client.

Một bucket giả định có thể cho phép các đợt burst ngắn sau một giai đoạn yên ắng trong khi vẫn hạn chế được hoạt động dài hạn. Hành vi đó có thể phù hợp với lưu lượng tương tác, nhưng có thể không phù hợp cho backend không thể hấp thụ burst. Hãy chọn dung lượng dựa trên khả năng xử lý thực tế của dịch vụ thay vì sao chép một giá trị mặc định chỉ vì nó khớp với tốc độ trung bình mong muốn.

Bài tổng quan thuật toán giới hạn tần suất mô tả các khái niệm token bucket và leaky bucket. Thuật ngữ leaky bucket có thể chỉ các thiết kế policing hoặc shaping khác nhau, vì vậy hãy nêu rõ liệu hiện thực của bạn từ chối các thao tác vượt mức hay xếp hàng chúng để xả ra với tốc độ có kiểm soát. Một tên gọi hiện thực là chưa đủ khi hai thư viện dùng cùng tên cho hành vi vận hành khác nhau.

Kế toán phân tán cần các quyết định nguyên tử

Một bộ giới hạn phân tán phải phối hợp việc kiểm tra và cập nhật của nó để các cuộc gọi đồng thời không thể cùng tiêu dùng phần dung lượng còn lại như nhau. Đọc một bộ đếm và cập nhật nó sau tạo ra điều kiện tranh chấp khi nhiều worker quan sát giá trị cũ. Hãy dùng một phép toán nguyên tử hoặc một cơ chế phối hợp khác phù hợp với kho trạng thái và yêu cầu nhất quán. Cách triển khai cụ thể thuộc về hạ tầng đã chọn.

Phối hợp cũng có chi phí. Một điểm quyết định tập trung có thể đơn giản hóa hạn mức toàn cục nghiêm ngặt nhưng thêm độ trễ mạng và một phụ thuộc. Hạn mức độc lập theo vùng có thể giảm phối hợp trong khi đòi hỏi một mô hình phân bổ và vượt hạn được xác định rõ. Hãy nêu rõ cam kết mà thiết kế thực sự cung cấp. Điều khiển phân tán xấp xỉ có thể hữu ích, nhưng không nên được quảng bá như một ngưỡng toàn cục chính xác nếu không có bằng chứng hỗ trợ.

Xử lý thời gian cũng cần độ rõ ràng tương tự. Hãy quyết định thành phần nào cung cấp thời gian dùng cho ranh giới cửa sổ hoặc tính toán nạp lại, trạng thái hết hạn như thế nào và điều gì xảy ra khi một tiến trình khởi động lại. Kiểm thử nên bao phủ cập nhật đồng thời và các thay đổi trong kho trạng thái, không chỉ một worker thực hiện các cuộc gọi cách đều nhau. Một bộ giới hạn trông có vẻ đúng trong minh họa một tiến trình có thể hành xử khác trên cả một cụm máy.

Tốc độ, đồng thời, quota và ngân sách là các khái niệm riêng biệt

Giới hạn tốc độ ràng buộc hoạt động theo thời gian, trong khi giới hạn đồng thời ràng buộc các thao tác đang xử lý. Một quota có thể ràng buộc tổng dài hạn hơn, và ngân sách tài chính có thể hạn chế chi tiêu. Một cơ chế không tự động thực thi những cơ chế khác. Một dịch vụ với các thao tác chậm và đắt có thể vẫn nằm trong giới hạn số yêu cầu nhưng làm cạn bộ nhớ hoặc tích lũy quá nhiều công việc đang hoạt động.

Số lượng yêu cầu cũng chỉ là một thước đo công việc. Một bản xuất lớn hoặc truy vấn phức tạp có thể tốn kém hơn nhiều so với một tra cứu nhỏ. Các cơ chế kiểm soát tiêu thụ tài nguyên của OWASP bao phủ kích thước payload, tần suất thao tác, số lượng bản ghi và chi tiêu dịch vụ. Hãy dùng các cơ chế đó khi chi phí tài nguyên không thể được biểu diễn đầy đủ bằng một token cho mỗi yêu cầu HTTP.

Ngữ nghĩa HTTP tạo thêm một điểm phân biệt: một yêu cầu được chấp nhận không phải lúc nào cũng là một thao tác nghiệp vụ đã hoàn thành. Các ngữ nghĩa phản hồi HTTP tách kết quả thông điệp khỏi cam kết xử lý của ứng dụng. Một thao tác xuất không đồng bộ có thể được chấp nhận và sau đó thất bại ở bước kiểm tra hợp lệ hoặc xử lý. Hãy quyết định ở giai đoạn nào một thao tác tiêu thụ mỗi loại ngân sách và cách hạch toán mô tả công việc không bao giờ tạo ra kết quả hữu ích.

Cạn kiệt và lỗi phụ thuộc cần chính sách rõ ràng

Một bộ giới hạn bị cạn nên tạo ra kết quả rõ ràng cho người gọi và cho chủ sở hữu thao tác. Từ chối, xếp hàng có giới hạn và bỏ bớt công việc chưa gửi có các hệ quả sản phẩm khác nhau. Hãy chọn hành vi dựa trên giá trị và thời hạn của tác vụ. Một hàng đợi không giới hạn có thể tiêu tốn bộ nhớ và khiến người dùng chờ đợi công việc sẽ không còn phù hợp khi dung lượng trở lại.

Một bộ giới hạn có kho trạng thái không khả dụng cần một chính sách phụ thuộc được xác định. Cho phép công việc mà không hạch toán có thể bảo vệ tính sẵn sàng trong khi làm yếu giới hạn; chặn công việc có thể bảo vệ ngân sách trong khi từ chối các yêu cầu hữu ích. Các thao tác khác nhau có thể cần quyết định khác nhau. Hãy ghi lại đánh đổi và kiểm thử qua các kịch bản lỗi có kiểm soát thay vì để hành vi tình cờ của thư viện lưu trữ trở thành chính sách.

Báo cáo lỗi nên xác định phạm vi bị ảnh hưởng mà không làm lộ thông tin xác thực hoặc hoạt động của tenant khác. Bao gồm một định danh chính sách, loại thao tác và một lý do đã được khử nhạy mà người gọi có thể hành động dựa vào. Người vận hành cần các số liệu tổng hợp về chấp nhận, từ chối, xếp hàng và xử lý. Số lượng từ chối cao có thể báo hiệu lạm dụng, phân bổ quá nhỏ hoặc lỗi client, và các nguyên nhân đó cần phản ứng khác nhau.

Quan sát tính công bằng và công việc hữu ích

Một bộ giới hạn tốt bảo vệ công việc hữu ích trong khi thực thi chính sách đã nêu. Đo lường ai nhận được dung lượng, công việc được chấp nhận chờ bao lâu và liệu các thao tác đắt đỏ có lấn át lưu lượng thông thường hay không. Phân bổ theo thứ tự đến trước có thể cho phép một tenant tiêu dùng toàn bộ hạn mức chia sẻ ngay cả khi từng yêu cầu riêng lẻ đều hợp lệ. Nếu công bằng là yêu cầu sản phẩm, nó cần một thiết kế phân bổ rõ ràng.

Tải kiểm thử nên bao gồm các đợt bùng nổ, nhu cầu tenant không đồng đều, thao tác chậm, đầu vào lớn và nhiều worker khởi động đồng thời. Giữ các kiểm thử đó trong môi trường staging được ủy quyền hoặc môi trường cục bộ với dữ liệu tổng hợp và khối lượng có giới hạn. Mục tiêu là xác nhận mô hình quyết định, không phải khám phá ngưỡng của dịch vụ sản xuất bằng cách áp đảo nó. So sánh số lượt được chấp nhận quan sát được với phạm vi và chính sách thời gian mong đợi.

Một báo cáo vận hành hữu ích tách biệt các yêu cầu được chấp nhận, thao tác đã hoàn thành, bản ghi được lưu trữ và mức tiêu thụ tài chính. Các giá trị này có thể khác nhau vì những lý do hợp lệ. Duy trì các phân biệt đó giúp nhóm thấy liệu bộ giới hạn có bảo vệ tài nguyên thực tế và liệu phân bổ có tạo ra kết quả sản phẩm như dự định hay không. Một tỷ lệ thành công đơn lẻ không thể giải thích tất cả những ranh giới đó.

Đặt bộ giới hạn xung quanh quy trình làm việc Scrapeless

Một client có thể đặt kiểm soát chấp nhận xung quanh các cuộc gọi tới Scrapeless Web Unlocker, trong khi các quy tắc tài khoản riêng của dịch vụ vẫn được áp dụng độc lập. Phần tổng quan Web Unlocker mô tả việc truy xuất nội dung dựa trên URL. Ứng dụng của bạn chọn phạm vi đích, xếp hàng công việc và quyết định liệu nội dung trả về có đáp ứng tiêu chí tập dữ liệu của nó hay không. Một bộ giới hạn cục bộ không thể thay đổi chính sách cấp quyền của trang web đích.

Đánh giá Bảng giá Scrapeless cho chi phí dịch vụ và các khái niệm độ đồng thời liên quan để kiểm soát công việc đang hoạt động. Áp dụng một hạn mức dùng chung cho các bên tiêu dùng sử dụng cùng một mức cho phép tài khoản. Giữ các điều kiện thu thập được ủy quyền của nguồn hiển thị cùng với ngân sách dịch vụ, vì năng lực mạng, năng lực tài chính và quyền thu thập dữ liệu là các ràng buộc riêng biệt.

Một tác vụ báo cáo giả định có thể dành trước một hạn mức hàng ngày có giới hạn, đặt trần số yêu cầu đang hoạt động và hết hạn các quan sát chưa gửi sau cửa sổ báo cáo của chúng. Báo cáo hoàn tất của nó nên xác định các bản ghi được chấp nhận và phạm vi chưa được thu thập. Thiết kế đó kết nối bộ giới hạn với một yêu cầu kinh doanh thực tế và khiến tập dữ liệu thu được dễ đánh giá hơn khi năng lực sẵn có nhỏ hơn nhu cầu.

Kết luận

Bộ giới hạn tốc độ là một hệ thống cấp quyền mà hành vi phụ thuộc vào phạm vi, mô hình thời gian, thuật toán và tính nhất quán trong ghi nhận. Hãy chọn các thuộc tính đó từ tài nguyên bạn cần bảo vệ, rồi kiểm thử các ranh giới của chúng với lưu lượng được kiểm soát. Kết hợp kiểm soát tốc độ với các giới hạn chi phí và công việc đang hoạt động mà ứng dụng yêu cầu, và báo cáo phần công việc hữu ích mà các yêu cầu được chấp nhận thực sự tạo ra.