下面是Redis適用的一些場景:

1. 取最新 N 個數(shù)據(jù)的操作

比如典型的取你網(wǎng)站的最新文章，通過下面方式，我們可以將最新的 5000條評論的ID放在Redis的List集合中，并將超出集合部分從數(shù)據(jù)庫獲取。

使用LPUSH latest.comments命令，向 list集合中插入數(shù)據(jù) 插入完成后再用 LTRIM latest.comments 0 5000 命令使其永遠只保存最近5000個 ID 然后我們在客戶端獲取某一頁評論時可以用下面的邏輯

FUNCTION get_latest_comments(start,num_items):
 id_list = redis.lrange("latest.comments",start,start+num_items-1) 
 IF id_list.length < num_items 
 id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...") 
 END 
 RETURN id_list 
END 

如果你還有不同的篩選維度，比如某個分類的最新 N 條，那么你可以再建一個按此分類的List，只存ID的話，Redis是非常高效的。

2. 排行榜應用，取 TOP N 操作

這個需求與上面需求的不同之處在于，前面操作以時間為權重，這個是以某個條件為權重，比如按頂?shù)拇螖?shù)排序，這時候就需要我們的 sorted set出馬了，將你要排序的值設置成 sorted set的score，將具體的數(shù)據(jù)設置成相應的 value，每次只需要執(zhí)行一條ZADD命令即可。

127.0.0.1:6379> zdd topapp 1 weixin
(error) ERR unknown command 'zdd'
127.0.0.1:6379> zadd topapp 1 weixin
(integer) 1
127.0.0.1:6379> zadd topapp 1 QQ
(integer) 1
127.0.0.1:6379> zadd topapp 2 meituan
(integer) 1
127.0.0.1:6379> zincrby topapp 1 meituan
"3"
127.0.0.1:6379> zincrby topapp 1 QQ
"2"
127.0.0.1:6379> zrank topapp QQ
(integer) 1
3) "meituan"
127.0.0.1:6379> zrank topapp weixin
(integer) 0
127.0.0.1:6379> zrange topapp 0 -1
1) "weixin"
2) "QQ"

3.需要精準設定過期時間的應用

比如你可以把上面說到的 sorted set 的 score 值設置成過期時間的時間戳，那么就可以簡單地通過過期時間排序，定時清除過期數(shù)據(jù)了，不僅是清除 Redis中的過期數(shù)據(jù)，你完全可以把 Redis 里這個過期時間當成是對數(shù)據(jù)庫中數(shù)據(jù)的索引，用 Redis 來找出哪些數(shù)據(jù)需要過期刪除，然后再精準地從數(shù)據(jù)庫中刪除相應的記錄。

4.計數(shù)器應用

Redis的命令都是原子性的，你可以輕松地利用 INCR，DECR 命令來構建計數(shù)器系統(tǒng)。

5.Uniq 操作，獲取某段時間所有數(shù)據(jù)排重值

這個使用Redis的 set數(shù)據(jù)結構最合適了，只需要不斷地將數(shù)據(jù)往 set中扔就行了，set意為集合，所以會自動排重。

6.實時系統(tǒng)，反垃圾系統(tǒng)

通過上面說到的 set功能，你可以知道一個終端用戶是否進行了某個操作，可以找到其操作的集合并進行分析統(tǒng)計對比等。

7.Pub/Sub 構建實時消息系統(tǒng)

Redis 的 Pub/Sub 系統(tǒng)可以構建實時的消息系統(tǒng)，比如很多用 Pub/Sub 構建的實時聊天系統(tǒng)的例子。

8.構建隊列系統(tǒng)

使用list可以構建隊列系統(tǒng)，使用 sorted set甚至可以構建有優(yōu)先級的隊列系統(tǒng)。

9.緩存

性能優(yōu)于Memcached，數(shù)據(jù)結構更多樣化。作為RDBMS的前端擋箭牌，redis可以對一些使用頻率極高的sql操作進行cache，比如，我們可以根據(jù)sql的hash進行SQL結果的緩存：

def get_results(sql):
    hash = md5.new(sql).digest()
    result = redis.get(hash)
    if result is None:
        result = db.execute(sql)
        redis.set(hash, result)
        # or use redis.setex to set a TTL for the key
    return result

10.使用setbit進行統(tǒng)計計數(shù)

下邊的例子是記錄UV

#!/usr/bin/python
import redis
from bitarray import bitarray
from datetime import date

r=redis.Redis(host='localhost', port=6379, db=0)
today=date.today().strftime('%Y-%m-%d')

def bitcount(n):
len(bin(n)-2)

def setup():
r.delete('user:'+today)
r.setbit('user:'+today,100,0)

def setuniquser(uid):
r.setbit('user:'+today,uid,1)

def countuniquser():
a = bitarray()
a.frombytes(r.get('user:'+today),)
print a
print a.count()

if __name__=='__main__':
setup()
setuniquser(uid=0)
countuniquser()

11.維護好友關系

使用set進行是否為好友關系，共同好友等操作

12.使用 Redis 實現(xiàn)自動補全功能

使用有序集合保存輸入結果：

ZADD word:a 0 apple 0 application 0 acfun 0 adobe
ZADD word:ap 0 apple 0 application
ZADD word:app 0 apple 0 application
ZADD word:appl 0 apple 0 application
ZADD word:apple 0 apple
ZADD word:appli 0 application

再使用一個有序集合保存熱度：

ZADD word_scores 100 apple 80 adobe 70 application 60 acfun

取結果時采用交集操作：

ZINTERSTORE word_result 2 word_scores word:a WEIGHTS 1 1
ZRANGE word_result 0 -1 withscores

13. 可靠隊列設計

? UUIDs as Surrogate Keys Our strategy spreads information about the state of an item in the queue across a number of Redis data structures, requiring the use of a per-item surrogate key to tie them together. The UUID is a good choice here because 1) they are quick to generate, and 2) can be generated by the clients in a decentralized manner. ? Pending List The Pending List holds the generated UUIDs for the items that have been enqueued(), and are ready to be processed. It is a RedisList, presenting the generated UUIDs in FIFO order. ? Values Hash The Values Hash holds the actual items that have been enqueued. It is a Redis Hash, mapping the generated UUID to the binary form of the the item. This is the only representation of the original item that will appear in any of the data structures. ? Stats Hash The Stats Hash records some timestamps and counts for each of the items. Specifically: ? enqueue time ? last dequeue time ? dequeue count ? last requeue time ? last requeue count. It is a Redis Hash, mapping the generated UUID to a custom data structure that holds this data in a packed, binary form. Why keep stats on a per-item basis? We find it really useful for debugging (e.g. do we have a bad apple item that is being continuously requeued?), and for understanding how far behind we are if queues start to back up. Furthermore, the cost is only ~40 bytes per item, much smaller than our typical queued items. ? Working Set The Working Set holds the set of UUIDs that have been dequeued(), and are currently being processed. It is a Redis Sorted Set, and scores each of the UUIDs by a pre-calculated, millisecond timestamp. Any object that has exceeded its assigned timeout is considered abandoned, and is available to be reclaimed. ? Delay Set The Delay Set holds the set of UUIDs that have been requeued() with a per-item deferment. It is a Redis Sorted Set, and scores each of the UUIDs by a pre-calculated, millisecond timestamp. Once the deferment timestamp has expired, the item will be returned to the Pending List. Why support per-item deferment? We have a number of use cases where we might want to backoff specific pieces of work — maybe an underlying resource is too busy — without backing off the entire queue. Per-item deferment lets us say, “requeue this item, but don’t make it available for dequeue for another n seconds.”