Best Practices for Using Alibaba Cloud Redis: Key Design, Command Usage, Client Configuration, and Tools

1. Key Design

Use a business or database prefix separated by a colon (e.g., business:table:id ) to avoid collisions, ensure readability, and manageability. Keep keys concise, avoid special characters, spaces, or line breaks, and aim for short lengths to reduce memory overhead.

Example: ugc:video:1 can be simplified to u:{uid}:fr:m:{mid} .

2. Value Design

Limit string values to 10 KB and keep hash, list, set, and sorted‑set elements under 5 000 items to prevent big‑key issues that cause network traffic spikes and slow queries. Avoid storing massive collections (e.g., a list with 2 million elements).

For non‑string big keys, use incremental deletion via hscan , sscan , or zscan instead of DEL , and be cautious with expiration‑triggered deletions that may block the server.

3. Command Usage

Prefer O(N) commands only when the size N is known; replace full scans with hscan , sscan , or zscan . Disable risky commands such as KEYS , FLUSHALL , and FLUSHDB via Redis’ rename mechanism.

Avoid using multiple logical databases (SELECT) as they add complexity and can cause interference.

Batch operations improve efficiency: use native multi‑key commands like MGET , MSET or pipeline non‑atomic commands, keeping batch sizes around 500 elements to balance latency and memory usage.

4. Client Usage

Do not share a single Redis instance across unrelated services; isolate business domains and expose shared data via services.

Employ connection pools to control connections and improve throughput.

In high‑concurrency scenarios, add circuit‑breaker mechanisms (e.g., Netflix Hystrix) and enable SSL/TLS for secure access.

5. Memory Eviction Policies

Select an appropriate maxmemory-policy based on workload. The default volatile‑lru evicts expired keys using LRU, while alternatives include allkeys‑lru , allkeys‑random , volatile‑random , volatile‑ttl , and noeviction (which rejects writes when memory is full).

6. Related Tools

Data synchronization can be performed with redis‑port . Use big‑key search utilities and hot‑key detection (monitor‑based, short‑lived) to identify performance bottlenecks.

7. Appendix – Deleting Big Keys

Hash: hscan + hdel

List: ltrim

Set: sscan + srem

Sorted Set: zscan + zrem

These operations can be accelerated with pipelines, and Redis 4.0+ supports asynchronous key deletion.