Cache Selection and Usage Guidelines for Ximalaya Services

Cache is a critical component for Ximalaya, handling massive daily request volumes. To ensure service stability and performance, a set of cache selection and usage standards is presented.

1. Cache Selection

Four cache types are used in Ximalaya:

Redis master‑slave (official version)

Codis‑Redis (open‑source Redis cluster solution)

Cloud Database Redis (containerized Redis‑cluster deployment)

XCache (self‑developed KV store based on Codis, Pika, Redis)

Two usage modes are defined:

Cache mode : data is non‑persistent, no data loading on instance recovery, and scaling does not require data migration.

Store mode : data must be persisted, instance recovery requires loading data, and scaling requires data migration.

A comparison of the four cache types shows that master‑slave Redis, Codis‑Redis, and Cloud Redis provide fast recovery in cache mode, while XCache adds native persistence and supports massive data volumes.

2. Cache Usage Rules

2.1 Cache Type Usage

Prefer Cloud Database Redis for Redis‑cluster deployments; choose XCache for massive KV storage.

Do not use Redis as a primary database; if persistence is required, use XCache.

Avoid client‑side sharding; use true cluster solutions such as Codis‑Redis, Cloud Redis, or XCache.

Cluster mode does not support Lua or Redisson clients; use Redis master‑slave if those are required.

Limit single‑node Redis capacity to 10 GB and XCache capacity to 200 GB.

2.2 Key Design Guidelines

Keep keys short, readable, and manageable; use business name as prefix (e.g., biz:table:id ) and avoid special characters.

Reject big keys: strings ≤10 KB, hash/list/set/zset elements ≤5 000.

Avoid hot keys; distribute load across multiple keys.

Set TTL for all keys and stagger expirations to prevent mass expiration spikes.

2.3 Command Usage Guidelines

Disable KEYS * ; avoid HGETALL , SMEMBERS ; use SCAN with small batch sizes (≤200).

Limit batch commands ( MSET , MGET , HMSET , HMGET , *SCAN , *RANGE ) to ≤200 elements per call.

Limit pipeline size to ≤100 commands.

Use UNLINK instead of DEL for large key deletions.

Combine SET and EXPIRE into SETEX to reduce write pressure.

Prefer EVALSHA over EVAL in Redis‑cluster to reduce network I/O.

2.4 Architecture and Operational Guidelines

Do not use logical DBs in Redis; stick to default DB 0.

Isolate different business data into separate clusters; avoid sharing a single cache resource across multiple services.

Prefer STRING type in XCache for best performance (STRING > HASH > SET > EHASH > LIST > ZSET).

Minimize Lua script usage; keep scripts simple and avoid complex logic.

Compress large values with tools like Snappy or GZIP to save memory.

Throttle batch, scheduled, and periodic tasks to avoid overwhelming online traffic.

Assess capacity and QPS impact before business changes; monitor during peak periods.

Recycle unused resources promptly to reduce storage costs.