TencentDB for Redis®
- Release Notes and Announcements
- Product Introduction
- Product Series
- Purchase Guide
- Getting Started
- Operation Guide
- Access Management
- SDK Connection
- Daily Instance Operation
- Upgrading Redis Edition Instances
- Managing Redis Edition Nodes
- Multi-AZ Deployment Management
- Backup and Restoration
- Downloading Redis Edition Backups
- Data Migration for Redis Edition Instances
- Account and Password (Redis Edition)
- Parameter Configuration
- Redis Parameter Operations
- Network and Security
- Monitoring and Alarms
- Redis Edition Event Management
- Global Replication for Redis Edition
- Performance Optimization
- Development Guidelines
- Connection Pool Configuration
- Command Reference
- Commands Supported by Different Versions
- Additional Command Operations in the Redis Edition
- Troubleshooting
- Connection Exception
- Performance Troubleshooting and Fine-Tuning
- Practical Tutorial
- API Documentation
- Making API Requests
- Instance APIs
- Parameter Management APIs
- Other APIs
- Backup and Restoration APIs
- Monitoring and Management APIs
- Service Agreement
Basic Usage Guidelines
Last updated: 2024-11-05 10:22:22
Cache-Only Policy
Redis is only used to cache data. It stores all data in memory for quicker access. However, using it to persist data may result in data loss because it can’t store data in memory persistently after a power failure.
Non-Unique Data Source Policy
Since Redis is used for caching, cache misses are possible, so it cannot be relied upon as the sole source of data. In case of an exception when accessing Redis, the backend database needs to be queried.
Key Eviction Policy
Set the
maxmemory-policy as needed. The default policy is noeviction, which means that keys will not be deleted. When memory is used up, OOM will occur. So we recommend that you modify the eviction policy once the instance is created to reduce OOM.Configurable memory eviction policy
Select one of the following eviction policies for maxmemory-policy when the Redis in-memory cache was used up. LRU (least recently used) and TTL (time to live) are implemented by randomized and approximation algorithms.
allkeys-lru: Delete keys based on the LRU algorithm, regardless of whether the data has a timeout attribute, until enough space is freed up.
allkeys-random: Randomly delete keys until enough space is freed up.
volatile-lru: Delete expired keys based on the LRU algorithm until enough space is freed up.
volatile-random: Randomly delete expired keys until enough space is freed up.
volatile-ttl: Delete data that is about to be expired based on the TTL attribute of key-value pairs. If there is no recently expiring data, the policy will fall back to "noeviction".
noeviction: Evict no data, reject all write operations, and return the error message "(error) OOM command not allowed when used memory" to the client. Redis will only respond to read operations.
Suggestions
When Redis is used as a cache, it is recommended to use the "allkeys-lru" eviction policy. This policy evicts the keys least frequently used. By default, if a key is least frequently used, it is also less likely to be accessed in the future, so it is evicted.
When Redis is used as data persistence and caching in a hybrid manner, the volatile-lru policy can be used. As Redis is not recommended to store data persistently, it is only considered as an alternative.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No