Tair (Redis® OSS-Compatible):Development and O&M standards for Tair (Redis OSS-compatible)

Resource type

Description

Computing resources

Wildcards, concurrent Lua scripts, one-to-many PUBSUB, and hotkeys consume heavy computing resources. For cluster instances, these items can also cause request skew and shard underutilization.

Storage resources

Streaming jobs and large keys consume heavy storage resources. For cluster instances, these items can also cause data skew and shard underutilization.

Network resources

Database-wide scans (KEYS) and range queries on large keys and values (HGETALL) consume heavy network resources and often cause thread congestion.

Importance

Standard

Description

★★★★★

• High-speed cache: Disable AOF persistence in cache-only scenarios to reduce overhead. Avoid strong dependence on cached data — when a Tair database reaches its maximum storage capacity, a data eviction policy triggers to free space, which can increase latency under heavy write loads.

  Important

  To use the data flashback feature to restore data by point in time, you must enable AOF persistence.

• In-memory databases: Choose Tair (Enterprise Edition) persistent memory-optimized instances. Persistent memory-optimized instances offer command-level persistence. Monitor memory usage through Alert settings.

★★★★★

Deploy your application in the same virtual private cloud (VPC) as your Tair instances, such as on an Elastic Compute Service (ECS) instance.

Tair delivers high performance, but deploying far from Tair instances or connecting over the Internet significantly degrades performance due to network latency.

★★★★☆

Create a Tair instance for each service.

Do not share a Tair instance across services. Mixing cache and in-memory database workloads causes eviction policies, slow queries, and FLUSHDB command execution of one service to affect others.

★★★★☆

Configure appropriate eviction policies to evict expired keys.

The default eviction policy for expired keys in Tair is volatile-lru . Configure eviction policies in Parameters that can be configured for Redis Open-Source Edition instances.

★★★☆☆

Manage stress testing data and duration.

Tair does not delete stress testing data. To prevent impacts on your business, you must manage stress testing data and duration yourself.

Importance

Standard

Description

★★★★★

Keep values below 10 KB.

Oversized values cause data skew, hotkeys, high bandwidth, or high CPU utilization.

★★★★★

Use descriptive, concise key names.

• Key names:

  • Use readable strings. Separate database, table, and field components with colons (:). Example: project:user:001.

  • Shorten key names without losing meaning. For example, username can be shortened to u.

  • In Redis, braces {} are hash tags. In cluster instances, use braces correctly in key names to prevent data skew . Redis cluster specification.

    Note

    For a cluster instance, if you want to manage multiple keys with a command such as RENAME and do not use hash tags to place the keys in the same data shard, the command fails.

• Length: Keep key names within 128 bytes, preferably shorter.

★★★★★

Limit sub-keys per complex data structure to fewer than 1,000.

The time complexity of commands like HGETALL scales with sub-key count. Frequent O(N)+ commands on keys with excessive sub-keys cause slow queries, data skew, and hotkeys.

★★★★☆

Serialize values into readable structures.

Language bytecode can change between versions. Storing raw objects (Java, C#) in Tair makes stack upgrades difficult. Serialize values into readable structures instead.

Importance

Standard

Description

★★★★★

Use JedisPool or JedisCluster to connect to Tair instances.

Single connections cannot automatically reconnect after a timeout. Configure JedisPool connections: Use a client to connect to an instance, JedisPool optimization, and JedisCluster.

★★★★☆

Design proper fault tolerance mechanisms for your clients.

Network fluctuations and high usage of resources may cause connection timeouts or slow queries in Tair. To prevent these risks, you must design proper fault tolerance mechanisms for your clients.

★★★★☆

Use adequate retry intervals.

Retry intervals shorter than 200 ms can trigger rapid retries and cause a service avalanche. Retry mechanisms for Redis clients.

Importance

Standard

Description

★★★★★

Avoid range queries such as KEYS *. Use point queries or SCAN instead.

Range queries may cause service interruptions, slow queries, or congestion.

★★★★★

Use extended data structures (Integration of multiple data modules) instead of Lua scripts.

Lua scripts consume heavy computing and memory resources without multi-threading support. Complex or improper scripts can exhaust resources.

★★★★☆

Use pipelines to reduce the round-trip time (RTT) of data.

When your client does not depend on individual responses, batch commands with a pipeline. Guidelines:

• Establish a dedicated connection for pipeline operations, separate from regular operations.

• Limit each pipeline to 100 commands or fewer.

★★★★☆

Use Redis commands correctly.

Transaction command limits:

• Redis transactions cannot be rolled back.

• If you want to run transaction commands on cluster instances, use hash tags to allocate keys to the same hash slot. Prevent the storage skew that hash tags can cause.

• Do not wrap transaction commands in Lua scripts — compilation and loading consume heavy computing resources.

★★★★☆

Avoid large-scale message distribution with Pub/Sub commands.

Pub/Sub lacks data persistence and acknowledgment mechanisms. Distributing messages larger than 1 KB to over 100 subscribers can exhaust server resources and cause message loss.

Importance

Standard

Description

★★★★★

Understand the impacts of different instance management operations.

Configuration changes or restarts can cause transient disconnections on a Tair instance. Understand the impacts before proceeding. Instance states and impacts.

★★★★★

Test client error handling and disaster recovery logic.

Tair monitors node health and automatically triggers master-replica switchover when a master becomes unavailable. Before a client goes to production, manually trigger a switchover to verify error handling and disaster recovery logic. Manually switch workloads from a master node to a replica node.

★★★★★

Disable time-consuming or high-risk commands.

Command abuse in production can cause data loss (FLUSHALL) or network congestion (KEYS). Disable risky commands to improve stability. Disable high-risk commands.

★★★★☆

Handle pending events promptly.

Alibaba Cloud generates pending events for hardware upgrades, software updates, or network maintenance — for example, when a minor database version needs updating. Review the impact and reschedule if needed. View and manage scheduled events.

★★★★☆

Configure alerts for core metrics.

Monitor CPU utilization, memory usage, and bandwidth in real time with Alert settings.

★★★★☆

Regularly check instance health using Tair O&M features to troubleshoot resource anomalies.

• Use slow query logs to troubleshoot timeout issues: Locate slow queries and source client IPs to resolve timeout issues.

• View the performance monitoring data: Tair provides performance metrics to monitor service health and troubleshoot issues promptly.

• Create a diagnostic report: Evaluate instance status — performance levels, request skew, and slow query logs — and identify exceptions.

• Use the offline key analysis feature: Identify large keys and analyze their memory usage, distribution, and TTL.

• Use the real-time key statistics feature: Identify hotkeys to optimize database performance.

★★★☆☆

Enable the audit log feature and evaluate audit logs.

The audit log feature records write operations and supports querying, online analysis, and export. Use it to monitor instance security and performance. Audit Log.