AFAIK, không thể định cấu hình Redis để loại bỏ dữ liệu cũ một cách nhất quán trước.
Khi các tùy chọn * -ttl hoặc * -lru được chọn trong maxmemory-policy, Redis không sử dụng một thuật toán chính xác để chọn các khóa cần xóa. Một thuật toán chính xác sẽ yêu cầu một danh sách bổ sung (cho * -lru) hoặc một đống bổ sung (cho * -ttl) trong bộ nhớ và tham chiếu chéo nó với cấu trúc dữ liệu từ điển Redis thông thường. Nó sẽ tốn kém về tiêu thụ bộ nhớ.
Với cơ chế hiện tại, việc loại bỏ xảy ra trong vòng lặp sự kiện chính (tức là lần loại bỏ tiềm năng được kiểm tra ở mỗi lần lặp lại vòng lặp trước khi mỗi lệnh được thực thi). Cho đến khi bộ nhớ hoạt động trở lại dưới giới hạn bộ nhớ tối đa, Redis chọn ngẫu nhiên một mẫu gồm n khóa và chọn khóa không hoạt động nhất (đối với * -lru) hoặc khóa gần nhất với giới hạn hết hạn (đối với * -ttl) sẽ hết hạn. Theo mặc định, chỉ có 3 mẫu được xem xét. Kết quả là không xác định.
Một cách để tăng độ chính xác của thuật toán này và giảm thiểu vấn đề là tăng số lượng mẫu được xem xét (tham số maxmemory-samples trong tệp cấu hình). Không đặt nó quá cao, vì nó sẽ tiêu tốn một số CPU. Đó là sự cân bằng giữa độ chính xác của việc trục xuất và mức tiêu thụ CPU.
Bây giờ nếu bạn thực sự yêu cầu một hành vi nhất quán, một giải pháp là triển khai cơ chế đuổi của riêng bạn trên Redis. Ví dụ:bạn có thể thêm một danh sách (đối với các khóa không thể cập nhật) hoặc một tập hợp được sắp xếp (đối với các khóa có thể cập nhật) để theo dõi các khóa sẽ bị loại bỏ trước. Sau đó, bạn thêm một daemon có mục đích là kiểm tra định kỳ (sử dụng INFO) mức tiêu thụ bộ nhớ và truy vấn các mục của danh sách / tập hợp đã sắp xếp để xóa các khóa có liên quan.
Xin lưu ý rằng các hệ thống bộ nhớ đệm khác có cách riêng để giải quyết vấn đề này. Ví dụ với memcached, có một cấu trúc LRU trên mỗi phiến (phụ thuộc vào kích thước đối tượng), vì vậy thứ tự loại bỏ cũng không chính xác (mặc dù xác định hơn so với Redis trong thực tế).
