Tair (Redis® OSS-Compatible):Use Tair to build a live-streaming channel information system

Real-time ranking

Pattern: Use a sorted set when you need to rank members by a numeric score and retrieve the top N entries in O(log N) time.

Sorted sets fit real-time ranking because every member carries a score and Redis keeps members in score order automatically. This means scores can be updated continuously — as they are for live comments, virtual gift leaderboards, and online user lists — without a full re-sort on each read.

Use a Unix timestamp combined with a millisecond offset as the score. This gives each live comment a unique, time-ordered position in the sorted set.

The following example tracks live comments in the user55:_danmu key.

Add five live comments with timestamp scores:

redis> ZADD user55:_danmu 1523959031601166 message111111111111
(integer) 1
redis> ZADD user55:_danmu 1523959031601266 message222222222222
(integer) 1
redis> ZADD user55:_danmu 1523959088894232 message33333
(integer) 1
redis> ZADD user55:_danmu 1523959090390160 message444444
(integer) 1
redis> ZADD user55:_danmu 1523959092951218 message5555
(integer) 1

Retrieve the three most recent comments:

redis> ZREVRANGEBYSCORE user55:_danmu +inf -inf LIMIT 0 3
1) "message5555"
2) "message444444"
3) "message33333"

Retrieve the three most recent comments up to a specific timestamp:

redis> ZREVRANGEBYSCORE user55:_danmu 1523959088894232 -inf LIMIT 0 3
1) "message33333"
2) "message222222222222"
3) "message111111111111"

ZREVRANGEBYSCORE returns members from highest score to lowest, so the newest comments appear first. The LIMIT 0 3 clause caps the result to three entries. Passing a specific timestamp as the upper bound lets you paginate through older comments.

Counting

Pattern: Use a hash when you need to group multiple counters for the same entity and increment each field atomically in O(1) time.

Hashes fit user counters because a single key groups all counter fields for one user — follower count, unread messages, experience points — and HINCRBY updates each field atomically. Concurrent increments from multiple connections never produce incorrect counts.

The following example tracks the follower count for user 55.

Set the initial follower count:

redis> HSET user:55 follower 5
(integer) 1

Increment the follower count by 1:

redis> HINCRBY user:55 follower 1
(integer) 6

Read all fields for the user:

redis> HGETALL user:55
1) "follower"
2) "6"

The same user:55 key can hold additional fields (unread_messages, experience_points) without changing the key structure or the update logic.

Timeline

Pattern: Use a list when you need to prepend new events and retrieve the most recent N entries in O(1) time.

Lists store items in insertion order and support O(1) prepends. Pushing new events to the head with LPUSH and reading the most recent N events with LRANGE matches the access pattern for chronological activity feeds — anchor moments and new posts for user 55.

The following example records activity events for user 55.

Add two activity events:

redis> LPUSH user:55_recent_activity '{datetime:201804112010,type:publish,title:The show starts,content:Come on}'
(integer) 1
redis> LPUSH user:55_recent_activity '{datetime:201804131910,type:publish,title:Ask for a leave,content:Sorry, I have plans today.}'
(integer) 2

Retrieve the 11 most recent events:

redis> LRANGE user:55_recent_activity 0 10
1) "{datetime:201804131910,type:publish,title:Ask for a leave,content:Sorry, I have plans today.}"
2) "{datetime:201804112010,type:publish,title:The show starts,content:Come on}"

Because LPUSH prepends to the list, LRANGE 0 10 always returns the most recent events first, with no sorting step.

What's next

• To identify hot keys in your live-streaming workload, see Use the real-time key statistics feature.

• To analyze key usage offline and find performance bottlenecks, see Use the offline key analysis feature.

• To handle high concurrency by scaling out your Tair instance, see Cluster master-replica instances.