Cache Location and Eviction Policy

ダウンロード

フォーカスモード

フォントサイズ

最終更新日: 2026-09-07 14:45:19

AI翻訳・品質チェック済み

Distributed Cache supports multiple storage engines, including Redis, Valkey, and Memcached, storing data in memory to achieve microsecond-level read and write response times. However, memory resources are limited and data is not persistent after a power outage. Therefore, before using it, you must clarify two prerequisites: a cache instance should be positioned as a cache, not a persistent database, and you must configure a reasonable eviction policy to prevent service interruption after memory is fully utilized. This document defines the basic guidelines for cache usage and provides recommendations for selecting an eviction policy.
I. Cache Location Guidelines
A cache instance should be used only as a cache. It stores all data in memory, providing fast access. However, data stored in memory is not persistent after a power outage. If you use a cache instance as a persistent database, data loss may occur.
II. Non-Unique Data Source Guidelines
When a cache instance is used as a cache, cache misses can occur. Therefore, it should not be used as the sole data source. When an exception occurs during a call to the cache instance or a cache miss happens, you must fall back to querying the backend database (such as MySQL or PostgreSQL) to ensure the integrity of business data.
III. Key Eviction Guidelines
Configure an appropriate eviction policy, maxmemory-policy, based on your business type. The default policy is noeviction (which does not evict any keys). When memory is fully utilized, this policy rejects all write operations and returns an OOM error. We recommend that you modify the eviction policy immediately after an instance is created to prevent service interruption due to memory exhaustion. For instructions on how to configure parameters, see Managing Instance Parameters.
3.1 Eviction Algorithm Description
Abbreviation
Full Name
Description
LRU
Least Recently Used
Least recently used. Tracks the last access time of each key, and prioritizes evicting the keys that have been least recently accessed.
LFU
Least Frequently Used
Least frequently used. Tracks the number of accesses of each key, and prioritizes evicting the keys with the fewest accesses.
TTL
Time To Live
Time to live. Measures the remaining time for a key before it expires.
3.2 Optional Memory Eviction Policies
Policy
Scope
Eviction Rule
allkeys-lru
All keys
Prioritizes evicting the least recently used keys until sufficient space is freed.
allkeys-lfu
All keys
Prioritizes evicting the least frequently accessed keys until sufficient space is freed.
allkeys-random
All keys
Randomly evicts keys until sufficient space is freed.
volatile-lru
Keys with an expiration time set
Prioritizes evicting the least recently used keys among those with a TTL set.
volatile-lfu
Keys with an expiration time set
Prioritizes evicting the least frequently accessed keys among those with a TTL set.
volatile-ttl
Keys with an expiration time set
Prioritizes evicting keys with a smaller TTL value (that is, those about to expire). If no keys have a TTL set, rolls back to the noeviction policy.
volatile-random
Keys with an expiration time set
Randomly evicts keys with an expiration time set.
noeviction
—
Does not delete any data, rejects all write operations and returns the error message "(error) OOM command not allowed when used memory", and only responds to read operations at this time.
3.3 Eviction Policy Selection Recommendations
Notes:
Persistent data is not recommended to be stored in a cache instance itself. volatile-lru serves only as a fallback option for hybrid scenarios.
Scenario
Recommended Policy
Description
Use as a Pure Cache (Recommended).
allkeys-lru
All keys can be evicted, with the least recently accessed keys removed first. Keys with the lowest access frequency have the lowest subsequent hit probability, resulting in minimal business impact after eviction.
Some Keys Need to Be Persistently Retained.
volatile-lru
Evicts only keys with an expiration time set, leaving keys without an expiration time unaffected. Suitable for hybrid scenarios containing both cache data (with TTL set) and configuration data (without TTL set).
Requires Precise Control Over Key Lifecycle.
volatile-ttl
Prioritizes evicting keys that are about to expire, suitable for scenarios with explicit requirements on data timeliness.
Correct example: After an instance is created, change the eviction policy from the default noeviction to allkeys-lru.
# View the current eviction policy.
CONFIG GET maxmemory-policy
﻿
# Set it to allkeys-lru.
CONFIG SET maxmemory-policy allkeys-lru
Incorrect example: The following configuration may cause issues.
Configuration Method
Issue Description
Using the default noeviction policy without modification.
All write operations are rejected after memory is full, an OOM error is returned, and service writes are interrupted.
Using volatile-lru when no keys have TTL set.
The volatile-* policy only applies to keys with an expiration time set. If no keys have a TTL set, it is equivalent to the noeviction policy, and memory cannot be freed.
Using the allkeys-random policy to handle prioritized cache data.
Random eviction does not distinguish access frequency, which may accidentally delete frequently accessed hot keys, leading to a decrease in cache hit rate.

ヘルプとサポート

この記事はお役に立ちましたか？

営業担当者にお問い合わせいただくかチケットを提出してサポートを求めることができます。

フィードバック

tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Cache Location and Eviction Policy

I. Cache Location Guidelines

II. Non-Unique Data Source Guidelines

III. Key Eviction Guidelines

3.1 Eviction Algorithm Description

3.2 Optional Memory Eviction Policies

3.3 Eviction Policy Selection Recommendations

ヘルプとサポート

Abbreviation	Full Name	Description
LRU	Least Recently Used	Least recently used. Tracks the last access time of each key, and prioritizes evicting the keys that have been least recently accessed.
LFU	Least Frequently Used	Least frequently used. Tracks the number of accesses of each key, and prioritizes evicting the keys with the fewest accesses.
TTL	Time To Live	Time to live. Measures the remaining time for a key before it expires.

Policy	Scope	Eviction Rule
`allkeys-lru`	All keys	Prioritizes evicting the least recently used keys until sufficient space is freed.
`allkeys-lfu`	All keys	Prioritizes evicting the least frequently accessed keys until sufficient space is freed.
`allkeys-random`	All keys	Randomly evicts keys until sufficient space is freed.
`volatile-lru`	Keys with an expiration time set	Prioritizes evicting the least recently used keys among those with a TTL set.
`volatile-lfu`	Keys with an expiration time set	Prioritizes evicting the least frequently accessed keys among those with a TTL set.
`volatile-ttl`	Keys with an expiration time set	Prioritizes evicting keys with a smaller TTL value (that is, those about to expire). If no keys have a TTL set, rolls back to the `noeviction` policy.
`volatile-random`	Keys with an expiration time set	Randomly evicts keys with an expiration time set.
`noeviction`	—	Does not delete any data, rejects all write operations and returns the error message `"(error) OOM command not allowed when used memory"`, and only responds to read operations at this time.

Scenario	Recommended Policy	Description
Use as a Pure Cache (Recommended).	`allkeys-lru`	All keys can be evicted, with the least recently accessed keys removed first. Keys with the lowest access frequency have the lowest subsequent hit probability, resulting in minimal business impact after eviction.
Some Keys Need to Be Persistently Retained.	`volatile-lru`	Evicts only keys with an expiration time set, leaving keys without an expiration time unaffected. Suitable for hybrid scenarios containing both cache data (with TTL set) and configuration data (without TTL set).
Requires Precise Control Over Key Lifecycle.	`volatile-ttl`	Prioritizes evicting keys that are about to expire, suitable for scenarios with explicit requirements on data timeliness.

Configuration Method	Issue Description
Using the default `noeviction` policy without modification.	All write operations are rejected after memory is full, an OOM error is returned, and service writes are interrupted.
Using `volatile-lru` when no keys have TTL set.	The `volatile-*` policy only applies to keys with an expiration time set. If no keys have a TTL set, it is equivalent to the `noeviction` policy, and memory cannot be freed.
Using the `allkeys-random` policy to handle prioritized cache data.	Random eviction does not distinguish access frequency, which may accidentally delete frequently accessed hot keys, leading to a decrease in cache hit rate.