Redis offers a rich set of data types, each designed for specific use cases. Understanding when to применять each type is crucial for building efficient applications. This comprehensive guide explores the practical scenarios where each Redis data type shines, from basic string operations to advanced geospatial calculations.

Common Application Patterns

Leaderboards

Virtually every e-commerce platform and content site incorporates some form of ranking system—whether it is sales rankings, trending products, or user engagement metrics. Redis's sorted set structure provides an elegant foundation for implementing complex leaderboard functionality with minimal overhead.

Real-Time Counters

Counters serve as fundamental components in modern applications: product view counts, video playback numbers, API request tracking. Each view requires an imediate increment operation. At high concurrency levels, database-backed counters introduce significant performance bottlenecks. Redis's atomic increment operations execute entirely in memory, delivering exceptional performance for high-throughput counting scenarios.

Distributed Session Management

In containerized environments with limited applications, built-in session replication often suffices. However, as system complexity grows and applications scale horizontally, managing sessions at the container level becomes unwieldy. A centralized session service built on Redis or similar in-memory stores decouples session management from application containers, providing consistent session handling across distributed deployments.

Distributed Locking

Distributed systems introduce significant concurrency challenges when multiple nodes compete for shared resources. Scenarios like generating unique identifiers, inventory management during flash sales, and preventing race conditions require robust locking mechanisms. While data base locks work for low-concurrency situations, they become inadequate under heavy load. Redis's atomic SET-if-Not-Exists operation forms the foundation of distributed locking implementations.

Social Features

Core social functionality—likes, follows, mutual connections, friend recommendations—requires efficient storage and retrieval of relationship data. Traditional relational databases struggle with the dynamic, interconnected nature of social graphs. Redis's hash and set structures naturally model these relationships, enabling performant social feature implementations.

Activity Feeds

Redis lists excel at maintaining chronological feeds. Using LPUSH to prepend content identifiers and LTRIM to enforce size limits creates a fixed-size window of recent activity. This approach eliminates query overhead—content retrieval happens directly through known identifiers.

Message Queuing

Message queues form the backbone of event-driven architectures, anabling业务解耦,流量削峰, and asynchronous processing. While dedicated solutions like RabbitMQ and Kafka offer enterprise-grade features, Redis's publish-subscribe and blocking queue capabilities support simpler messaging requirements.

---

String Type

Strings represent Redis's most fundamental data type, functioning as key-value pairs where values can contain any binary data up to 512MB. This versatility makes strings suitable for numerous scenarios.

Inventory Tracking

SET inventory:product:001 1500
SET inventory:product:002 750

User Profile Storage

SET profile:user:1045 '{"id":1045, "username":"alex_johnson", "status":"active"}'
SET profile:user:1046 '{"id":1046, "username":"maria_chen", "status":"pending"}'

Distributed Lock Implementation

The SET command with NX (only set if not exists) and EX (expiration) options creates a basic locking mechanism:

127.0.0.1:6379> SET lock:resource:order-001 1 EX 30 NX
OK
127.0.0.1:6379> GET lock:resource:order-001
"1"
# Subsequent attempts fail while lock is held
127.0.0.1:6379> SET lock:resource:order-001 1 EX 30 NX
(nil)
# Lock expires after 30 seconds
127.0.0.1:6379> GET lock:resource:order-001
(nil)

Hash Type

Hashes store field-value pairs within a single Redis key, providing a structured representation ideal for objects. Unlike serialized JSON strings, hashes allow individual field access without transferring entire objects.

User Profile Management

127.0.0.1:6379> HSET user:profile:3001 id 3001 name emily_wilson age 28 premium true
(integer) 4
127.0.0.1:6379> HSET user:profile:3002 id 3002 name david_park age 32 premium false
(integer) 4
127.0.0.1:6379> HMGET user:profile:3001 id name age premium
1) "3001"
2) "emily_wilson"
3) "28"
4) "true"

Configuration Objects

127.0.0.1:6379> HSET app:config:cache ttl 3600 max-connections 100 debug-enabled false
(integer) 3
127.0.0.1:6379> HGET app:config:cache ttl
"3600"
127.0.0.1:6379> HGETALL app:config:cache
1) "ttl"
2) "3600"
3) "max-connections"
4) "100"
5) "debug-enabled"
6) "false"

List Type

Redis lists implement doubly-linked lists, enabling efficient insertions and deletions at both ends. New lists are created automatically when referencing previously non-existent keys.

Asynchronous Task Processing

Lists serve as natural task queues where producers push work items and consumers process them:

127.0.0.1:6379> LPUSH queue:tasks email:send-001 email:send-002 analytics:batch-001
(integer) 3
127.0.0.1:6379> RPOP queue:tasks
"email:send-001"

Flash Sale Queue Management

127.0.0.1:6379> LPUSH flashsale:queue:campaign-2024 users:1001 users:1002 users:1003
(integer) 3

Set Type

Sets store unique string elements with O(1) complexity for additions, removals, and membership tests. Automatic deduplication makes sets ideal for tracking distinct items.

Daily Check-In Tracking

127.0.0.1:6379> SADD checkin:date:2024-01-16 user:1001 user:1002 user:1003 user:1004
(integer) 4
127.0.0.1:6379> SMEMBERS checkin:date:2024-01-16
1) "user:1001"
2) "user:1002"
3) "user:1003"
4) "user:1004"
127.0.0.1:6379> SISMEMBER checkin:date:2024-01-16 user:1002
(integer) 1

Interest-Based User Grouping

127.0.0.1:6379> SADD user:1045:interests technology travel photography cooking
(integer) 4
127.0.0.1:6379> SADD user:2098:interests technology gaming music cooking
(integer) 4
# Find common interests
127.0.0.1:6379> SINTER user:1045:interests user:2098:interests
1) "technology"
2) "cooking"
127.0.0.1:6379> SINTERSTORE user:1045:2098:shared user:1045:interests user:2098:interests
(integer) 2

Random Selection for Promotions

127.0.0.1:6379> SPROMO candidates user:3001 user:3002 user:3003 user:3004 user:3005
1) "user:3003"

Sorted Set Type

Sorted sets combine set uniqueness with ordered positioning. Each element associates with a numeric score determining its position in the ordering.

Check-In Leaderboard

127.0.0.1:6379> ZADD leaderboard:checkins 1610812987 user:1001
(integer) 1
127.0.0.1:6379> ZADD leaderboard:checkins 1610812980 user:1002
(integer) 1
127.0.0.1:6379> ZADD leaderboard:checkins 1610812950 user:1003
(integer) 1
127.0.0.1:6379> ZADD leaderboard:checkins 1610814950 user:1004
(integer) 1
127.0.0.1:6379> ZRANGEBYSCORE leaderboard:checkins 1610812950 1610812987 WITHSCORES
1) "user:1003"
2) "1610812950"
3) "user:1002"
4) "1610812980"
5) "user:1001"
6) "1610812987"

Bitmap Type

Bitmaps store binary data as compact bit arrays, offering dramatic space savings for boolean tracking. Each bit represents a binary state, enabling efficient range queries and set operations.

Monthly User Activity Tracking

127.0.0.1:6379> SETBIT user:activity:1045:2024-01 0 1
(integer) 0
127.0.0.1:6379> SETBIT user:activity:1045:2024-01 3 1
(integer) 0
127.0.0.1:6379> SETBIT user:activity:1045:2024-01 7 1
(integer) 0
127.0.0.1:6379> SETBIT user:activity:1045:2024-01 14 1
(integer) 0
127.0.0.1:6379> BITCOUNT user:activity:1045:2024-01 0 31
(integer) 4

Daily Site Visit Statistics

127.0.0.1:6379> SETBIT site:visits:2024-01-17 1 1
(integer) 0
127.0.0.1:6379> SETBIT site:visits:2024-01-17 3 1
(integer) 0
127.0.0.1:6379> SETBIT site:visits:2024-01-17 5 1
(integer) 0
127.0.0.1:6379> SETBIT site:visits:2024-01-17 7 1
(integer) 0
127.0.0.1:6379> BITCOUNT site:visits:2024-01-17 0 100
(integer) 4
127.0.0.1:6379> GETBIT site:visits:2024-01-17 2
(integer) 0

Cross-Period User Analysis

127.0.0.1:6379> SETBIT site:visits:2024-01-18 1 1
(integer) 0
127.0.0.1:0.6379> SETBIT site:visits:2024-01-18 3 1
(integer) 0
127.0.0.1:6379> SETBIT site:visits:2024-01-18 5 1
(integer) 0
127.0.0.1:6379> SETBIT site:visits:2024-01-18 7 1
(integer) 0
# Find users who visited both days
127.0.0.1:6379> BITOP AND visitors:both-days site:visits:2024-01-18 site:visits:2024-01-17
(integer) 1

HyperLogLog Type

HyperLogLog provides probabilistic cardinality estimation with minimal memory footprint. The tradeoff involves accepting approximately 0.81% error rate in exchange for remarkable space efficiency—storing millions of unique items requires merely 12KB.

Approximate Visit Counting

127.0.0.1:6379> PFADD analytics:unique:2024-01 session:001 session:002 session:003
(integer) 1
127.0.0.1:6379> PFADD analytics:unique:2024-01 session:004 session:005 session:006
(integer) 1
127.0.0.1:6379> PFADD analytics:unique:2024-01 session:001 session:002
(integer) 0
127.0.0.1:6379> PFCOUNT analytics:unique:2024-01
(integer) 6

Multi-Period Aggregation

127.0.0.1:6379> PFADD analytics:week:03 user:1001 user:1002 user:1003 user:1004
(integer) 1
127.0.0.1:6379> PFADD analytics:week:04 user:1002 user:1003 user:1005 user:1006 user:1007
(integer) 1
127.0.0.1:6379> PFMERGE analytics:fortnight analytics:week:03 analytics:week:04
OK
127.0.0.1:6379> PFCOUNT analytics:fortnight
(integer) 7

Geospatial Type

Geo commands store latitude/longitude pairs and enable distance calculations and proximity searches—essential for location-aware features.

Distance Calculations

127.0.0.1:6379> GEOADD locations:delivery nx 116.397128 39.916527 beijing 121.473701 31.230416 shanghai
(integer) 2
127.0.0.1:6379> GEOPOS locations:delivery beijing shanghai
1) 1) "116.39712989330291748"
   2) "39.91652744677382677"
2) 1) "121.47370147705078125"
   2) "31.23041623822096583"
127.0.0.1:6379> GEODIST locations:delivery beijing shanghai km
"1067.0157"

Stream Type

Introduced in Redis 5.0, streams provide persistent, consumer-group-capable message streaming. Unlike pub/sub, streams retain messages until explicitly deleted.

Event Streaming Implementation

127.0.0.1:6379> XADD events:orders * order-id ORD-2024-001 customer customer-1045 total 299.99
"1610873104343-0"
127.0.0.1:6379> XADD events:orders * order-id ORD-2024-002 customer customer:2098 total 149.50
"1610873104456-0"
127.0.0.1:6379> XRANGE events:orders - +
1) 1) "1610873104343-0"
   2) 1) "order-id"
      2) "ORD-2024-001"
      3) "customer"
      4) "customer-1045"
      5) "total"
      6) "299.99"
2) 1) "1610873104456-0"
   2) 1) "order-id"
      2) "ORD-2024-002"
      3) "customer"
      4) "customer-2098"
      5) "total"
      6) "149.50"
127.0.0.1:6379> XREAD COUNT 1 STREAMS events:orders $
1) 1) "events:orders"
   2) 1) 1) "1610873104456-0"
      2) 1) "order-id"
         2) "ORD-2024-002"
         3) "customer"
         4) "customer:2098"
         5) "total"
         6) "149.50"