Problem Index
Is Lua Scripting Supported?
Yes. The Lua feature is enabled by default in both the standard and cluster architectures. When using Lua scripts in the cluster architecture, ensure that all keys operated on in the script are in the same Slot. Otherwise, execution may fail.
Are Cache Invalidation Subscription Events Supported?
Yes. The distributed cache database supports subscription notifications for Key expiration events. You can subscribe to the __keyevent@*__:expired channel by running the PSUBSCRIBE command to listen for cache invalidation events.
What Are Big Keys and Hot Keys? How to Identify and Handle Them?
Big Key
A big key is a key with a large amount of data. The criteria for determining whether a key is a big key vary by data structure as follows:
|
String | Value size exceeds 10 KB. |
Hash,List,Set,ZSet | The number of elements exceeds 5,000. |
Main impacts of big keys:
Memory imbalance: In the cluster architecture, the memory utilization of nodes where big keys reside is significantly higher, leading to data skew.
Request blocking: Performing operations such as DEL and GETALL on big keys blocks the single-threaded Redis, causing timeouts for other requests.
Sync interruption: If a big Key is written during master-replica sync, a sync buffer overflow may be triggered, resulting in a full sync.
Hot Key
A hot key is a key that is accessed frequently. Criteria: The QPS of a single key exceeds 10% of the total QPS of the instance, or its access frequency far exceeds that of other keys. Main impacts of hot keys:
Under the cluster architecture, the CPU utilization of the shard where the hot Key resides is high.
Request blocking may occur when hot keys are dequeued or expire.
How to Identify Big Keys and Hot Keys?
Console big Key analysis: In the Diagnostics Analysis section of the instance details page, you can scan all keys with one click to identify big keys.
DBbrain intelligent diagnostics: Automatically discovers big keys and hot keys, and displays detailed information such as memory usage and access frequency.
Command mode: Scan big keys with redis-cli --bigkeys. Note: This command traverses all keys. We recommend that you run it on a replica node or during off-peak hours.
Handling method:
Split big keys: Split large strings into multiple smaller keys based on business dimensions. Split large hashes into multiple smaller hashes.
Hot Key distribution: Add business prefixes to hot keys (such as key_1, key_2, and key_3) to distribute them across different slots. Add a local cache at the business layer.
Timely cleanup: Delete useless big keys promptly to release memory.
How to Set a Cache Eviction Policy?
Log in to the distributed cache database console. On the parameter configuration page of the instance details, set the cache eviction policy through the maxmemory-policy parameter. The default value is noeviction (no eviction). Select an appropriate policy based on your business scenario: |
volatile-lru
| Evict the least recently used keys among those with expiration time set. |
allkeys-lru
| Evict the least recently used keys among all keys. |
volatile-ttl
| Evict keys that are about to expire among those with expiration time set. |
noeviction
| No eviction. Writes fail when memory is full (default). |
What to Do If a Write Fails Due to Insufficient Instance Memory?
When the instance memory usage reaches the upper limit and the eviction policy is noeviction (default), all write requests will return OOM (Out of Memory) errors. The handling steps are as follows:
Step 1: Check the Current Eviction Policy
In the console, check the maxmemory-policy parameter. If it is the default noeviction, the system will not proactively evict keys when the memory is full, and manual intervention is required.
Step 2: Short-Term Mitigation: Clean Up Unused Data
Use the SCAN command to traverse and clean up known useless keys.
If your business allows the loss of some cold data, temporarily change the eviction policy to allkeys-lru or volatile-lru to let the system automatically evict the least recently used keys.
Step 3: Long-Term Solution: Analyze Memory Usage
Use the big Key analysis feature in the console to identify the keys that occupy the most memory and optimize them.
Check whether many keys do not have a time-to-live (TTL) set, and set TTLs for temporary data.
If the data volume indeed exceeds the current specification capacity, perform an online capacity expansion to increase the memory limit.
Suggestions for selecting an eviction policy:
|
Pure cache scenario (data can be lost) | allkeys-lru
|
Cache and persistence hybrid | volatile-lru
|
Data loss prevention required | noeviction (with capacity alarm and capacity expansion)
|
Why Are Keys with Expiration Times Not Deleted Promptly?
Redis uses a dual mechanism of "lazy deletion + periodic scanning" to clean up expired keys. Therefore, expired keys are not immediately removed from memory:
Lazy deletion: An expired Key is checked and deleted only when it is accessed the next time. If an expired Key is never accessed again, it continues to occupy memory.
Periodic scanning: Redis randomly selects a batch of keys with expiration times set for checking every 100 ms and deletes the expired ones. This means that the cleanup of expired keys is random and subject to latency.
Common questions:
Q: Why are there more keys than expected when DBSIZE is executed?
Keys that have expired but have not yet been hit by lazy deletion or periodic scanning are still counted by DBSIZE. These keys are deleted upon subsequent access or cleaned up in the next periodic scan cycle, without affecting business logic (GET on an expired Key returns nil).
Q: What are the impacts of a large number of keys expiring at the same time (centralized expiration)?
If many keys have the same expiration time, the periodic scanning thread needs to process a large number of expired keys at the same time when they expire, which may cause a short-term increase in CPU utilization and even request latency jitter. You are advised to add a random offset to the expiration time:
EXPIRE key (3600 + random(0, 300))
Q: Why can expired keys be seen on the replica node?
A replica node does not proactively delete expired keys. It deletes them only after the master node sends a DEL command. Therefore, expired but undeleted keys may be visible when you run DBSIZE or SCAN on a replica node. This is by design in Redis master-replica replication and does not affect business reads (replica nodes on Redis 4.0 or later check the TTL and return nil when reading keys).
Why Should High-Risk Commands Be Disabled? How to Configure Them?
High-risk commands are Redis commands that may cause data loss or severely degrade performance. Distributed Cache Database supports disabling or renaming high-risk commands in the console to prevent online incidents caused by misoperations.
Common High-Risk Commands and Their Risks
|
KEYS *
| Iterates through all keys. When the instance has a large number of keys, Redis may be blocked for several seconds or even longer. |
FLUSHALL
| Deletes all data from all databases. The data cannot be restored. |
FLUSHDB
| Deletes all data from the current database. The data cannot be restored. |
CONFIG SET
| Dynamically modifies runtime configurations and may cause service exceptions. |
Disable Method
Log in to the console, go to Parameter Configuration on the instance details page, find the disabled-commands parameter, and add the names of the commands to be disabled (separate multiple commands with commas). After the configuration, the client receives an error message when executing a disabled command. For detailed operations, see Configuring Disabled Commands via disable-command-list. Alternative Solution
Use SCAN instead of KEYS * to iterate in batches with a cursor without blocking the main thread.
When data cleanup is required, verify by restoring from a backup to a new instance instead of directly executing FLUSHALL.
Configuration changes are made uniformly through the parameter configuration feature in the console instead of CONFIG SET.
What to Do If an Account Is Accidentally Deleted or a Password Is Forgotten?
Account Deleted by Mistake: Log in to the console, go to the account management page of the target instance, and create the account again.
Forgot Password: Find the corresponding account on the account management page and reset the password.
Note:
Resetting the password will interrupt connections that use the old password. Perform this operation during off-peak hours and notify relevant personnel in advance.
What Is the Hash Algorithm in Cluster Architecture?
The Hash algorithm in the cluster architecture is consistent with the community Redis Cluster and uses the CRC16 hashing algorithm:
HASH_SLOT = CRC16(key) mod 16384
All keys are evenly distributed across 16,384 hash slots by this algorithm, and each shard then manages its corresponding slots.
In Standard Architecture, Do select 0 - 15 Require Different Instances?
No. The standard architecture supports 16 databases by default (DB 0 - DB 15), so a single instance can meet the need for multiple databases. The cluster architecture supports up to 256 databases through Proxy.
What Is Pipeline and How to Use It?
Pipeline is a mechanism provided by Redis for executing commands in batches. It reduces network round-trip times (RTT) by packing multiple commands into a single request sent to the server, thereby improving the throughput of batch operations.
Performance Comparison
|
Execute one by one. | ≈ 1000ms (1000 network round trips) |
Pipeline (100 commands per batch) | ≈ 10ms (10 network round trips) |
Use Case
import redis
r = redis.Redis(host='<instance address>', port=6379, password='<password>')
pipe = r.pipeline(transaction=False)
for i in range(1000):
pipe.set(f'key:{i}', f'value:{i}')
results = pipe.execute()
Note for Use
1. Control the batch size per request: We recommend that each Pipeline contain 100 to 500 commands. Too many commands will cause the server to return a large amount of data at once, which may consume excessive memory or trigger bandwidth limits.
2. Non-atomicity: Pipeline only sends commands in batches and does not guarantee atomicity. If a command fails in the middle, other commands will not be rolled back. For atomic operations, use transactions (MULTI/EXEC).
3. Cluster architecture limitations: In the cluster architecture, commands in a Pipeline can be automatically routed by Proxy to different shards, without requiring the business side to be aware of Slot distribution. However, to ensure command ordering, it is recommended that commands in the same Pipeline access the same Key.
4. Timeout settings: The overall execution time of batch commands may be long, so increase the client read timeout accordingly.
5. Bandwidth risk warning: Batch returns from Pipeline may cause a sudden surge in outbound traffic. If an instance triggers a high outbound traffic alarm, reduce the number of commands per Pipeline request, or distribute batch operations across multiple time periods.