Bạn không nên quan tâm đến việc thực thi lệnh hiện tại mà là ảnh hưởng đến tất cả các lệnh khác, vì Redis xử lý các lệnh bằng một luồng duy nhất (tức là trong khi một lệnh đang được thực thi thì tất cả những lệnh khác cần phải đợi cho đến khi việc thực thi một lệnh kết thúc).
Trong khi các phím keys hoặc scan có thể cung cấp cho bạn hiệu suất tương tự hoặc giống hệt nhau được thực thi một mình trong trường hợp của bạn, một số mili giây chặn Redis sẽ làm giảm đáng kể I / O tổng thể.
Đây là lý do chính để sử dụng các khóa keys cho mục đích phát triển và scan trên môi trường sản xuất.
OP cho biết:
"Mặc dù khóa hoặc quét có thể cung cấp cho bạn hiệu suất tương tự hoặc giống hệt nhau được thực hiện riêng trong trường hợp của bạn, một số mili giây chặn Redis sẽ làm giảm đáng kể I / O tổng thể." - Câu này dường như chỉ ra rằng một lệnh chặn Redis, còn lệnh kia thì không, điều này không thể xảy ra. Nếu tôi được đảm bảo 100 kết quả từ cuộc gọi đến KEYS, thì điều đó tệ hơn SCAN ở điểm nào? Tại sao bạn cảm thấy rằng một lệnh hữu ích hơn để chặn?
Sẽ có một sự khác biệt tốt khi bạn có thể phân trang tìm kiếm. Việc buộc phải lấy 100 chìa khóa trong một lần vượt qua không giống với việc có thể thực hiện phân trang và nhận 100 chìa khóa, 10 x 10 (hoặc 50 và 50). Sự gián đoạn rất nhỏ này có thể cho phép các lệnh khác do lớp ứng dụng gửi đến được Redis xử lý . Xem tài liệu chính thức của Redis nói gì về điều này:
Vì các lệnh này cho phép lặp lại gia tăng, chỉ trả về số lượng phần tử nhỏ cho mỗi lần gọi, chúng có thể được sử dụng trong sản xuất mà không có nhược điểm của các lệnh như KEYS hoặc SMEMBERS có thể chặn máy chủ trong một thời gian dài (thậm chí vài giây) khi được gọi chống lại bộ sưu tập khóa lớn hoặc các phần tử
.
