Mastering Redis: Choosing the Right Data Type for High‑Performance Caching

1. Redis Data Types and Their Characteristics

Redis provides five core data types. String is the most frequently used because it is simple, can store complex objects such as JSON, and allows per‑key expiration.

Other types are used less often due to two main reasons: (1) they cannot set expiration on individual items within a collection, making cache invalidation more complex; (2) many developers are less familiar with their semantics, so they may overlook performance benefits in specific scenarios.

String

Strings store plain values and support EXPIRE directly on the key. They are ideal for caching JSON objects or any data that fits a single key.

Example:

SET string:order:100 order-100
TYPE string:order:100
# returns "string"

Strings can be dynamically composed, e.g., storing a set of IDs in a Set and then checking whether a corresponding String key exists to decide if the cache is still valid.

List

Lists support LPUSH, RPUSH, LPOP, and RPOP, making them perfect for producer‑consumer patterns and high‑throughput pipelines such as payment callback processing.

They are useful for implementing work‑stealing algorithms similar to Java’s Fork/Join framework.

Hash

Hashes provide O(1) field lookup and are suited for storing entity attributes that need frequent updates, such as page metrics or user profiles.

Atomic increment operations are available via HINCRBY and HINCRBYFLOAT:

HMSET hash:mall:page:ab:metrics:index topbanner 10 leftbanner 5 rightbanner 8
HINCRBY hash:mall:page:ab:metrics:index topbanner 1
# returns 11

Set

Sets store unique items and support powerful set operations (intersection, union, difference). They are often used to represent collections such as available product IDs and active promotion IDs, enabling fast filtering.

Example of intersecting two sets:

SADD set:marketing:product:available:ids 1000100 1000120 1000130
SADD set:marketing:activity:product:ids 1000100 1000140 1000200
SINTER set:marketing:product:available:ids set:marketing:activity:product:ids
# returns the common IDs

Zset (Sorted Set)

Zsets add a score to each member, allowing ordered retrieval. They are ideal for ranking scenarios such as sorting groups by participant count.

Typical commands:

ZADD zset:marketing:groupon:hottop:available:group 5 G1 10 G2 15 G3
ZRANGE zset:marketing:groupon:hottop:available:group 0 -1 WITHSCORES

Zset intersection (via ZINTERSTORE) can combine multiple ranking dimensions.

2. Case Study: Hujiang Groupon System Hot‑Top Interface Cache Design

The hot‑top interface displays the most popular groups during a large promotion. It must handle massive traffic, sort groups by participant count, and paginate results.

Key design steps:

Query condition : Cache the full list of group IDs for a given filter using a Hash that maps a generated code to the list.

Sorting : Store each group's participant count in a Zset. The Zset represents a global ranking of all groups.

Intersection : Use ZINTERSTORE to intersect the query‑condition Hash‑derived set with the global ranking Zset, producing a sorted subset for the current request.

Pagination : Retrieve the required page with ZREVRANGE on the intersected Zset.

Command flow (simplified):

# Cache query condition result as a Set of group IDs
SADD set:condition:2986080 G1 G2 G3

# Global Zset with participant counts
ZADD zset:marketing:groupon:hottop:available:group 5 G1 10 G2 15 G3

# Intersect condition set with global Zset (store in a temporary Zset)
ZINTERSTORE zset:condition:interstore 2 set:condition:2986080 zset:marketing:groupon:hottop:available:group

# Retrieve a page (e.g., items 2‑4) with scores
ZREVRANGE zset:condition:interstore 2 4 WITHSCORES

After obtaining the group IDs, a batch MGET fetches the corresponding String entries containing the full group details.

This design demonstrates how combining Redis data types—String for entity details, Set for query‑condition membership, and Zset for ranking—yields a highly performant cache for a hot‑spot interface.

Further considerations (not expanded here) include cache expiration policies tied to promotion rules, potential hash‑code collisions, and handling of edge cases where caching alone cannot satisfy complex query requirements.

Upcoming topics will dive into Redis internal memory structures and encoding mechanisms that enable these data types.