redis的常見使用場景

一、顯示最新的項目列表

下面這個語句經常使用來顯示最新項目，隨着數據多了，查詢毫無疑問會愈來愈慢。

SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10

在Web應用中，「列出最新的回覆」之類的查詢很是廣泛，這一般會帶來可擴展性問題。這使人沮喪，由於項目原本就是按這個順序被建立的，但要輸出這個順序卻不得不進行排序操做。

相似的問題就能夠用Redis來解決。好比說，咱們的一個Web應用想要列出用戶貼出的最新20條評論。在最新的評論邊上咱們有一個「顯示所有」的連接，點擊後就能夠得到更多的評論。

咱們假設數據庫中的每條評論都有一個惟一的遞增的ID字段。

咱們可使用分頁來製做主頁和評論頁，使用Redis的模板，每次新評論發表時，咱們會將它的ID添加到一個Redis列表：

LPUSH latest.comments <ID>

 

咱們將列表裁剪爲指定長度，所以Redis只須要保存最新的5000條評論：

LTRIM latest.comments 0 5000

每次咱們須要獲取最新評論的項目範圍時，咱們調用一個函數來完成（使用僞代碼）：

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

 

 

這裏咱們作的很簡單。在Redis中咱們的最新ID使用了常駐緩存，這是一直更新的。可是咱們作了限制不能超過5000個ID，所以咱們的獲取ID函數會一直詢問Redis。只有在start/count參數超出了這個範圍的時候，才須要去訪問數據庫。

咱們的系統不會像傳統方式那樣「刷新」緩存，Redis實例中的信息永遠是一致的。SQL數據庫（或是硬盤上的其餘類型數據庫）只是在用戶須要獲取「很遠」的數據時纔會被觸發，而主頁或第一個評論頁是不會麻煩到硬盤上的數據庫了。

二、刪除與過濾

咱們可使用LREM來刪除評論。若是刪除操做很是少，另外一個選擇是直接跳過評論條目的入口，報告說該評論已經不存在。

有些時候你想要給不一樣的列表附加上不一樣的過濾器。若是過濾器的數量受到限制，你能夠簡單的爲每一個不一樣的過濾器使用不一樣的Redis列表。畢竟每一個列表只有5000條項目，但Redis卻可以使用很是少的內存來處理幾百萬條項目。

三、排行榜相關

另外一個很廣泛的需求是各類數據庫的數據並不是存儲在內存中，所以在按得分排序以及實時更新這些幾乎每秒鐘都須要更新的功能上數據庫的性能不夠理想。

典型的好比那些在線遊戲的排行榜，好比一個Facebook的遊戲，根據得分你一般想要：

- 列出前100名高分選手

- 列出某用戶當前的全球排名

這些操做對於Redis來講小菜一碟，即便你有幾百萬個用戶，每分鐘都會有幾百萬個新的得分。

模式是這樣的，每次得到新得分時，咱們用這樣的代碼：

ZADD leaderboard <score> <username>

你可能用userID來取代username，這取決於你是怎麼設計的。

獲得前100名高分用戶很簡單：ZREVRANGE leaderboard 0 99。

用戶的全球排名也類似，只須要：ZRANK leaderboard <username>。

四、按照用戶投票和時間排序

排行榜的一種常見變體模式就像Reddit或Hacker News用的那樣，新聞按照相似下面的公式根據得分來排序：

score = points / time^alpha

所以用戶的投票會相應的把新聞挖出來，但時間會按照必定的指數將新聞埋下去。下面是咱們的模式，固然算法由你決定。

模式是這樣的，開始時先觀察那些多是最新的項目，例如首頁上的1000條新聞都是候選者，所以咱們先忽視掉其餘的，這實現起來很簡單。

每次新的新聞貼上來後，咱們將ID添加到列表中，使用LPUSH + LTRIM，確保只取出最新的1000條項目。

有一項後臺任務獲取這個列表，而且持續的計算這1000條新聞中每條新聞的最終得分。計算結果由ZADD命令按照新的順序填充生成列表，老新聞則被清除。這裏的關鍵思路是排序工做是由後臺任務來完成的。

五、處理過時項目

另外一種經常使用的項目排序是按照時間排序。咱們使用unix時間做爲得分便可。

模式以下：

- 每次有新項目添加到咱們的非Redis數據庫時，咱們把它加入到排序集合中。這時咱們用的是時間屬性，current_time和time_to_live。

- 另外一項後臺任務使用ZRANGE…SCORES查詢排序集合，取出最新的10個項目。若是發現unix時間已通過期，則在數據庫中刪除條目。

六、計數

Redis是一個很好的計數器，這要感謝INCRBY和其餘類似命令。

我相信你曾許屢次想要給數據庫加上新的計數器，用來獲取統計或顯示新信息，可是最後卻因爲寫入敏感而不得不放棄它們。

好了，如今使用Redis就不須要再擔憂了。有了原子遞增（atomic increment），你能夠放心的加上各類計數，用GETSET重置，或者是讓它們過時。

例如這樣操做：

INCR user:<id> EXPIRE

user:<id> 60

你能夠計算出最近用戶在頁面間停頓不超過60秒的頁面瀏覽量，當計數達到好比20時，就能夠顯示出某些條幅提示，或是其它你想顯示的東西。

七、特定時間內的特定項目

另外一項對於其餘數據庫很難，但Redis作起來卻垂手可得的事就是統計在某段特色時間裏有多少特定用戶訪問了某個特定資源。好比我想要知道某些特定的註冊用戶或IP地址，他們到底有多少訪問了某篇文章。

每次我得到一次新的頁面瀏覽時我只須要這樣作：

SADD page:day1:<page_id> <user_id>

固然你可能想用unix時間替換day1，好比time()-(time()%3600*24)等等。

想知道特定用戶的數量嗎？只須要使用SCARD page:day1:<page_id>。

須要測試某個特定用戶是否訪問了這個頁面？SISMEMBER page:day1:<page_id>。

八、實時分析正在發生的狀況，用於數據統計與防止垃圾郵件等

咱們只作了幾個例子，但若是你研究Redis的命令集，而且組合一下，就能得到大量的實時分析方法，有效並且很是省力。使用Redis原語命令，更容易實施垃圾郵件過濾系統或其餘實時跟蹤系統。

九、Pub/Sub

Redis的Pub/Sub很是很是簡單，運行穩定而且快速。支持模式匹配，可以實時訂閱與取消頻道。

十、隊列

你應該已經注意到像list push和list pop這樣的Redis命令可以很方便的執行隊列操做了，但能作的可不止這些：好比Redis還有list pop的變體命令，可以在列表爲空時阻塞隊列。

現代的互聯網應用大量地使用了消息隊列（Messaging）。消息隊列不只被用於系統內部組件之間的通訊，同時也被用於系統跟其它服務之間的交互。消息隊列的使用能夠增長系統的可擴展性、靈活性和用戶體驗。非基於消息隊列的系統，其運行速度取決於系統中最慢的組件的速度（注：短板效應）。而基於消息隊列能夠將系統中各組件解除耦合，這樣系統就再也不受最慢組件的束縛，各組件能夠異步運行從而得以更快的速度完成各自的工做。

此外，當服務器處在高併發操做的時候，好比頻繁地寫入日誌文件。能夠利用消息隊列實現異步處理。從而實現高性能的併發操做。