下面是redis适用的一些場景:
比如典型的取你網站的最新文章，通過下面方式，我們可以将最新的 5000條評論的id放在redis的list集合中，并将超出集合部分從資料庫擷取。
使用lpush latest.comments指令，向 list集合中插入資料 插入完成後再用 ltrim latest.comments 0 5000 指令使其永遠隻儲存最近5000個 id 然後我們在用戶端擷取某一頁評論時可以用下面的邏輯
如果你還有不同的篩選次元，比如某個分類的最新 n 條，那麼你可以再建一個按此分類的list，隻存id的話，redis是非常高效的。
這個需求與上面需求的不同之處在于，前面操作以時間為權重，這個是以某個條件為權重，比如按頂的次數排序，這時候就需要我們的 sorted set出馬了，将你要排序的值設定成 sorted set的score，将具體的資料設定成相應的 value，每次隻需要執行一條zadd指令即可。
比如你可以把上面說到的 sorted set 的 score 值設定成過期時間的時間戳，那麼就可以簡單地通過過期時間排序，定時清除過期資料了，不僅是清除 redis中的過期資料，你完全可以把 redis 裡這個過期時間當成是對資料庫中資料的索引，用 redis 來找出哪些資料需要過期删除，然後再精準地從資料庫中删除相應的記錄。
redis的指令都是原子性的，你可以輕松地利用 incr，decr 指令來建構計數器系統。
這個使用redis的 set資料結構最合适了，隻需要不斷地将資料往 set中扔就行了，set意為集合，是以會自動排重。
通過上面說到的 set功能，你可以知道一個終端使用者是否進行了某個操作，可以找到其操作的集合并進行分析統計對比等。
redis 的 pub/sub 系統可以建構實時的消息系統，比如很多用 pub/sub 建構的實時聊天系統的例子。
使用list可以建構隊列系統，使用 sorted set甚至可以建構有優先級的隊列系統。
性能優于memcached，資料結構更多樣化。作為rdbms的前端擋箭牌，redis可以對一些使用頻率極高的sql操作進行cache，比如，我們可以根據sql的hash進行sql結果的緩存：
下邊的例子是記錄uv
使用set進行是否為好友關系，共同好友等操作
使用有序集合儲存輸入結果：
再使用一個有序集合儲存熱度：
取結果時采用交集操作：
• 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.”
<b></b>
<b>redis開發運維實踐指南</b>
<b>本文為《redis開發運維實踐指南》内容，該書作者為黃鵬程，已授權雲栖社群轉載。</b>