Giới hạn tốc độ là gì?

Scrapeless Web Unlocker thu thập nội dung web công khai cho các quy trình dữ liệu mà các caller vẫn phải thực thi các tỷ lệ yêu cầu rõ ràng, tính công bằng và khả năng hạ nguồn.

Tóm tắt

Giới hạn tốc độ kiểm soát các hoạt động theo thời gian. Nó bảo vệ khả năng, tính công bằng, chi phí và các mục tiêu dịch vụ bằng cách quyết định khi nào công việc có thể tiến hành.
Khóa xác định ranh giới chia sẻ. Giới hạn có thể áp dụng theo tài khoản, thông tin xác thực, tuyến đường, máy chủ, người thuê, khu vực, hoặc chủ đề được xác định khác.
Thuật toán hình thành hành vi bùng phát. Cửa sổ cố định, cửa sổ trượt, thùng token, và thùng rò rỉ tạo ra các thỏa hiệp khác nhau.
Đồng thời và tỷ lệ là tách biệt. Một hệ thống có thể có ít yêu cầu đang hoạt động và vẫn vượt quá dung lượng cho phép mỗi phút, hoặc ngược lại.
Khách hàng cần quyết định có thể quan sát được. Một phản hồi giới hạn nên xác định ranh giới chính sách và truyền đạt khi nào khả năng trở nên có sẵn khi giao thức hỗ trợ điều đó.

Định nghĩa Giới hạn Tốc độ

Một giới hạn tốc độ là một cơ chế kiểm soát cho phép, trì hoãn, hoặc từ chối các hoạt động theo chính sách được đo lường theo thời gian. Hoạt động có thể là một yêu cầu HTTP, thông điệp, nỗ lực đăng nhập, gửi công việc, truy vấn tốn kém, hoặc gọi đến một sự phụ thuộc có chỉ số. Chính sách liên kết một số lượng với một danh tính và một mô hình thời gian.

Bộ giới hạn nằm trên một đường dẫn tiếp nhận. Nó đọc một khóa, kiểm tra trạng thái, cập nhật trạng thái đó một cách nguyên tử, và trả về một quyết định. Kết quả bảo vệ một tài nguyên khan hiếm hoặc quy tắc công bằng trước khi nhu cầu không kiểm soát đến thành phần mà sẽ thất bại hoặc trở nên quá tốn kém. Thuật ngữ chính được sử dụng ở đây tuân theo định nghĩa RFC 6585 của HTTP 429, điều này cung cấp cho khái niệm một ranh giới kỹ thuật cụ thể thay vì coi nó như một nhãn tiếp thị.

Một định nghĩa hữu ích cũng nói rõ những gì khái niệm không làm. Một giới hạn tốc độ không giống như một semaphore đồng thời, dung lượng hàng đợi, hạn mức thanh toán, hoặc kiểm soát tắc nghẽn mạng. Những cơ chế đó có thể hoạt động cùng nhau, nhưng mỗi cái đo lường một điều kiện khác nhau và tạo ra một phản ứng khác nhau. Giữ cho ranh giới đó rõ ràng ngăn chặn các sơ đồ kiến trúc không giao cho một thành phần mà thuộc về một lớp khác những đảm bảo.

Cách Quyết Định Giới Hạn Tốc Độ Được Đưa Ra

Mỗi quyết định kết hợp một chủ thể, một quy tắc, trạng thái đã lưu, và một hành động. Một bộ giới hạn phân tán cũng cần các quy tắc nhất quán để nhiều cổng không mỗi cổng tiêu tốn toàn bộ hạn mức một cách độc lập.

Sử dụng khóa giới hạn từ tài khoản đã xác thực, tuyến đường, máy chủ, người thuê, hoặc ranh giới được phê duyệt khác.
Tải bộ đếm, dấu thời gian, số dư thùng, hoặc thời gian khởi hành trong hàng đợi cần thiết theo thuật toán đã chọn.
Áp dụng chính sách một cách nguyên tử để các yêu cầu đồng thời không thể tiêu tốn cùng một dung lượng hai lần.
Cho phép, trì hoãn, hoặc từ chối hoạt động và tiết lộ đủ siêu dữ liệu để quan sát và hành vi của khách hàng.
Hết hạn hoặc nén trạng thái bộ giới hạn để các khóa không hoạt động không tạo ra sự tăng trưởng lưu trữ không giới hạn.

Một cửa sổ cố định đếm trong các khoảng thời gian riêng biệt và đơn giản nhưng cho phép một sự bùng phát ranh giới. Một cửa sổ trượt làm mượt cạnh đó với nhiều trạng thái hoặc xấp xỉ. Một thùng token tích lũy quyền lên đến giới hạn, cho phép những sự bùng phát có kiểm soát. Một thùng rò rỉ định hình việc khởi hành theo một dòng chảy ổn định hơn. Hành vi này được tài liệu hóa đầy đủ hơn trong bảng thuật ngữ giới hạn tốc độ MDN. Nguồn này hữu ích vì nó mô tả quá trình thực hiện thực tế hoặc mô hình dữ liệu thay vì dựa vào một phép so sánh lỏng lẻo.

So Sánh Các Thuật Toán Giới Hạn Tốc Độ

Thuật toán	Hành vi bùng phát	Thỏa hiệp điển hình
Cửa sổ cố định	Bùng phát cạnh lớn có thể xảy ra	Trạng thái đơn giản nhưng công bằng thô
Nhật ký trượt	Chính xác trong khoảng thời gian lăn	Cần nhiều bộ nhớ và công việc dọn dẹp
Bộ đếm trượt	Tỷ lệ lăn xấp xỉ mượt mà hơn	Xấp xỉ gần các ranh giới
Thùng token	Cho phép bùng phát lên đến dung tích thùng	Cần logic nạp lại và chi tiêu nguyên tử
Xô có lỗ	Hình dạng đầu ra hướng đến một tốc độ ổn định	Thêm độ trễ hàng đợi hoặc loại bỏ bùng phát

Việc chọn thuật toán tuân theo hành vi sản phẩm. Các khách hàng tương tác có thể cần một cú đột phá vừa phải theo sau bởi một mức trung bình ổn định. Hệ thống theo lô có thể thích các xuất phát có nhịp độ. Các điểm cuối nhạy cảm về bảo mật có thể sử dụng các quy tắc chặt chẽ hơn theo từng danh tính cộng với bảo vệ toàn cầu riêng biệt.

Nơi mà các Bộ giới hạn Tốc độ Bảo vệ Hệ thống

API công cộng

Các giới hạn bảo tồn quyền truy cập công bằng giữa các tài khoản và ngăn một cuộc gọi từ việc tiêu thụ công suất yêu cầu chung.

Xác thực

Các chính sách chặt chẽ hơn có thể làm chậm các nỗ lực lặp lại trong khi vẫn bảo tồn quyền truy cập tài khoản bình thường và tín hiệu kiểm toán.

Công việc nền

Các kiểm soát tiếp nhận ngăn các nhà sản xuất làm cho các hàng đợi công nhân bị quá tải và các dịch vụ hạ nguồn tốn kém.

Ranh giới chi phí

Các mô hình metered hoặc phụ thuộc vào bên thứ ba có thể được bảo vệ bằng ngân sách phù hợp với loại đối tác và loại hoạt động.

Các trường hợp sử dụng này chia sẻ một quy tắc lựa chọn: chọn một bộ giới hạn tốc độ vì mô hình thực thi và quyền sở hữu của nó phù hợp với khối lượng công việc, chứ không phải vì tên nghe có vẻ tiên tiến hơn. Một giới hạn toàn cầu đơn lẻ hiếm khi đủ cho một dịch vụ đa người thuê. Các quy tắc phân tầng có thể bảo vệ toàn bộ hệ thống, một người thuê và một lộ trình tốn kém mà không cung cấp cho mọi yêu cầu cùng một giả định chi phí.

Khóa, Hạn ngạch và Công bằng

Một chính sách hữu ích nêu rõ ai chia sẻ công suất, hoạt động nào tiêu thụ nó, tốc độ trả lại công suất như thế nào, liệu có cho phép bùng phát hay không, và điều gì mà người gọi quan sát khi giới hạn được đạt đến.

Chọn một khóa đáng tin cậy. Một địa chỉ không được xác thực có thể nhóm người dùng không liên quan hoặc thay đổi trong một phiên, trong khi một khóa tài khoản gán trực tiếp hơn đến quyền sở hữu.
Ghi giá các hoạt động theo chi phí. Một xuất khẩu nặng và một tra cứu siêu dữ liệu có thể cần trọng số khác nhau thay vì một yêu cầu tương đương với một đơn vị.
Lớp các quy tắc toàn cầu và địa phương. Bảo vệ dịch vụ như một tổng thể trong khi vẫn bảo tồn công bằng theo từng người thuê và công suất cụ thể của lộ trình.
Giữ quyết định nguyên tử. Các cổng phân phối cần trạng thái chung hoặc được phân vùng mà không thể chi tiêu vượt quá số tiền cho phép.
Tiết lộ kết quả của chính sách. Các chỉ số và phản hồi giao thức nên phân biệt giữa sự cạn kiệt tỷ lệ và xác thực, xác nhận, và lỗi máy chủ.

Trạng thái HTTP 429 xác định một điều kiện tỷ lệ yêu cầu, nhưng máy chủ vẫn chọn cách xác định người gọi và đếm yêu cầu. Các khách hàng nên coi phản hồi như một tín hiệu chính sách, trong khi các chủ sở hữu dịch vụ nên tài liệu hóa các phạm vi giới hạn ổn định và tránh tiết lộ các chi tiết thi hành nhạy cảm. Một tài liệu tham khảo chính liên quan là hướng dẫn giới hạn yêu cầu NGINX, mà làm rõ các giả định về lưu trữ, thực thi, hoặc khả năng tương tác đằng sau sự lựa chọn đó.

Lỗi Thiết kế Bộ giới hạn Tốc độ

Một bộ giới hạn có thể xuất hiện chính xác dưới tải trung bình và vẫn thất bại ở các ranh giới, trong thời gian sai lệch đồng hồ, hoặc khi nhiều cổng cập nhật cùng một trạng thái. Các lỗi công bằng thường ẩn mình bên trong việc chọn khóa hơn là thuật toán đếm.

Nhầm lẫn tỷ lệ với độ song song. Một chính sách theo giây và một chính sách tối đa hoạt động bảo vệ các chiều khác nhau và nên được đo riêng biệt.
Tin tưởng vào đồng hồ của khách hàng. Các quyết định phía máy chủ nên sử dụng các nguồn thời gian có kiểm soát và xác định hành vi trong suốt quá trình di chuyển đồng hồ.
Sử dụng một khóa không ổn định. Một danh tính thay đổi hoặc dễ dàng nhân lên làm cho sự công bằng không nhất quán và trạng thái khó diễn giải.
Quên ý nghĩa của bùng phát. Hai chính sách có cùng tỷ lệ trung bình có thể tạo ra các đỉnh sau rất khác nhau.
Mở cửa sai do vô tình. Một sự cố lưu trữ cần một quyết định rõ ràng giữa khả năng sẵn có và bảo vệ cho mỗi lộ trình.

Một thất bại nên được truy nguyên đến lớp có trách nhiệm nhỏ nhất. Khi một người gọi báo cáo sự từ chối không mong đợi, hãy kiểm tra khóa đã được suy diễn, quy tắc áp dụng, số dư đã lưu trữ, thời gian quyết định, và trạng thái khu vực trước khi thay đổi tỷ lệ đã được công bố. Thực hành này tạo ra một hành động điều chỉnh hữu ích thay vì một chỉ dẫn mơ hồ để thêm nhiều công suất.

Kiểm soát Tốc độ trong Thu thập Dữ liệu Web

Việc thu thập web cần kiểm soát tốc độ ngay cả khi nhà cung cấp thu mua có thể chấp nhận nhiều cuộc gọi đồng thời. Máy chủ mục tiêu, ngân sách tài khoản, phân tích viên, lớp lưu trữ, và người tiêu dùng có mỗi công suất độc lập mà nên định hình việc tiếp nhận.

Đối với đầu vào web công cộng, lớp thu thập nên ghi lại URL đã yêu cầu, URL cuối cùng, thời gian thu thập, chế độ phản hồi, và một kiểm tra nội dung trước khi xử lý hạ nguồn bắt đầu. Đính kèm khóa giới hạn và tên chính sách vào siêu dữ liệu công việc nội bộ mà không tiết lộ thông tin xác thực hoặc trạng thái thi hành nhạy cảm. Sự chuyển giao đó cung cấp cho các nhà phân tích một hồ sơ nguồn tái tạo và giữ cho hành vi thu thập tách biệt với việc diễn giải.

Scrapeless xử lý bước thu thập web được quản lý như đã mô tả trong câu mở đầu. Ứng dụng vẫn sở hữu sự phê duyệt nguồn, định nghĩa trường, giới hạn khối lượng công việc, lưu giữ, các kiểm soát quyền truy cập, và xác nhận. Scrapeless sở hữu hoạt động thu hồi đã yêu cầu, trong khi người gọi sở hữu quyền xác thực nguồn, nhịp độ theo từng máy chủ, công bằng của người thuê, ngân sách, và tải hạ nguồn. Một hợp đồng rõ ràng giữa các lớp đó làm cho các thay đổi sau này dễ kiểm tra hơn.

Dòng chảy nên bảo tồn cả bằng chứng thô và đầu ra đã được chuẩn bị khi trường hợp sử dụng cần tính khả thi. Nguyên liệu thô hỗ trợ việc xử lý lại sau khi phân tích viên hoặc lược đồ thay đổi; các bảng đã được chuẩn bị hỗ trợ phân tích ổn định. Một hàng đợi không nên trở thành cách để lách chính sách tỷ lệ; lập lịch công việc theo độ mới và loại bỏ các công việc không còn hữu ích trước khi thu thập. Hai đại diện này trả lời các câu hỏi hoạt động khác nhau và không nên bị nhầm lẫn là bản sao.

Danh sách kiểm tra đánh giá giới hạn tỷ lệ

Sử dụng các câu hỏi sau trong quá trình xem xét thiết kế. Một câu trả lời bằng văn bản có giá trị hơn một mặc định được giả định vì nó cho thấy nơi mà các nhóm không đồng ý về một giới hạn tỷ lệ.

Khóa giới hạn đại diện cho danh tính hoặc tài nguyên nào?
Mỗi thao tác tiêu thụ đơn vị nào?
Chính sách là tỷ lệ trung bình, cho phép bùng nổ, giới hạn song song, hay là sự kết hợp?
Trạng thái của bộ giới hạn được lưu trữ và cập nhật ở đâu một cách nguyên tử?
Cách mà các cổng khu vực chia sẻ hoặc phân vùng các khoản cho phép?
Gọi là gì khi không có khả năng có sẵn?
Làm thế nào để các khóa cũ hết hạn mà không làm mất trạng thái hoạt động?
Bảng điều khiển nào hiển thị công bằng và sức khỏe tài nguyên được bảo vệ cùng nhau?

Một bộ giới hạn tỷ lệ đã sẵn sàng khi danh tính, mô hình thời gian, tính nguyên tử, hành động quá tải và khả năng quan sát phù hợp với tài nguyên được bảo vệ và hợp đồng đối mặt với người dùng. Hãy xem xét lại các câu trả lời sau khi hình dạng khối công việc, khối lượng dữ liệu, giới hạn dịch vụ hoặc mong đợi của người tiêu dùng thay đổi. Một kiến trúc hợp lý cho một lô thí nghiệm có thể không phù hợp cho một con đường sản xuất liên tục.

Kết luận

Một bộ giới hạn tỷ lệ biến mục tiêu về khả năng hoặc công bằng thành một quyết định cho phép theo thời gian. Sự hiệu quả của nó phụ thuộc vào việc chọn khóa, thuật toán, chính sách bùng nổ, trạng thái phân phối, và một phản hồi rõ ràng từ khách hàng. Các hệ thống mạnh mẽ kết hợp kiểm soát tỷ lệ với các giới hạn đồng thời, hàng đợi có giới hạn, ngân sách chi phí, và giám sát. Bộ giới hạn nên bảo vệ hành vi dịch vụ hữu ích, không chỉ đơn giản là tạo ra số lượng yêu cầu bị từ chối.

Sẵn sàng xây dựng một quy trình thu thập nhận thức về tỷ lệ?

Ghép nối truy xuất web công khai có quản lý với nhịp độ rõ ràng, hàng đợi công bằng, kiểm tra bằng chứng, và kiểm soát chi phí.

Đăng ký ngay hôm nay và nhận $5 tín dụng miễn phí — không yêu cầu thẻ tín dụng.

Từ chối tín dụng $5 của bạn →

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

Sự khác biệt giữa giới hạn tỷ lệ và hạn chế là gì?

Các thuật ngữ thường được sử dụng thay thế cho nhau, nhưng hạn chế có thể cụ thể nghĩa là trì hoãn hoặc định hình công việc trong khi giới hạn tỷ lệ cũng có thể từ chối nó. Một tài liệu thiết kế nên nêu rõ hành động thực tế: cho phép, chờ đợi, từ bỏ, hoặc từ chối. Chỉ việc đặt tên không cho khách hàng biết cách mà khả năng trở nên có sẵn.

Sự khác biệt giữa một giới hạn tỷ lệ và một hạn mức là gì?

Giới hạn tỷ lệ kiểm soát tốc độ xảy ra của các thao tác trong một mô hình thời gian. Hạn mức thường giới hạn tổng sử dụng trong một khoảng thời gian liên quan đến thanh toán, hợp đồng, hoặc hành chính. Một yêu cầu có thể đáp ứng chính sách tỷ lệ ngắn hạn trong khi vẫn vượt quá hạn mức dài hạn, vì vậy các hệ thống sản xuất thường thực thi cả hai.

Tại sao HTTP sử dụng trạng thái 429?

Trạng thái HTTP 429 xác định rằng người dùng đã gửi quá nhiều yêu cầu trong một khoảng thời gian nhất định. Thông số kỹ thuật để lại phương pháp đếm và xác định người dùng cho máy chủ. Một phản hồi có thể bao gồm thông tin cho khách hàng biết khi nào một yêu cầu khác là phù hợp, tùy thuộc vào hợp đồng dịch vụ.

Thuật toán giới hạn tỷ lệ nào là tốt nhất?

Không có thuật toán nào là tốt nhất cho mọi khối công việc. Các cửa sổ cố định ưa thích sự đơn giản, các phương pháp trượt làm mượt các ranh giới của cửa sổ, các thùng token cho phép bùng nổ có kiểm soát, và các thùng rò rỉ định hình đầu ra. Chọn từ độ chính xác yêu cầu, hành vi bùng nổ, chi phí lưu trữ, mô hình phân phối, và kinh nghiệm mà các người gọi hợp pháp mong đợi.

Giới hạn đồng thời API cao có loại bỏ nhu cầu về bộ giới hạn tỷ lệ không?

Không. Các giới hạn đồng thời giữ công việc hoạt động ở một thời điểm trong khi bộ giới hạn tỷ lệ kiểm soát các thao tác theo thời gian. Một khách hàng có thể vẫn dưới giới hạn đồng thời và vẫn gửi quá nhiều yêu cầu ngắn trong một phút. Các dịch vụ hạ nguồn, các máy chủ mục tiêu và ngân sách cũng có thể cần giới hạn chặt chẽ hơn so với nhà cung cấp.