幾點建議,讓Redis在你的系統中發揮更大做用~~~ 轉自CSDN

Redis在不少方面與其餘數據庫解決方案不一樣:它使用內存提供主存儲支持,而僅使用硬盤作持久性的存儲;它的數據模型很是獨特,用的是單線程。另外一個大區別在於,你能夠在開發環境中使用Redis的功能,但卻不須要轉到Redis。 html

轉向Redis固然也是可取的,許多開發者從一開始就把Redis做爲首選數據庫;但設想若是你的開發環境已經搭建好,應用已經在上面運行了,那麼更換數據庫框架顯然不那麼容易。另外在一些須要大容量數據集的應用,Redis也並不適合,由於它的數據集不會超過系統可用的內存。因此若是你有大數據應用,並且主要是讀取訪問模式,那麼Redis並非正確的選擇。 redis

然而我喜歡Redis的一點就是你能夠把它融入到你的系統中來,這就可以解決不少問題,好比那些你現有的數據庫處理起來感到緩慢的任務。這些你就能夠經過Redis來進行優化,或者爲應用建立些新的功能。在本文中,我就想探討一些怎樣將Redis加入到現有的環境中,並利用它的原語命令等功能來解決傳統環境中碰到的一些常見問題。在這些例子中,Redis都不是做爲首選數據庫。 算法

顯示最新的項目列表 數據庫

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

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

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

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

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

咱們可使用分頁來製做主頁和評論頁,使用Redis的模板: post

-每次新評論發表時,咱們會將它的ID添加到一個Redis列表: 性能

 LPUSH latest.comments <ID> 

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

 LTRIM latest.comments 0 5000 

-每次咱們須要獲取最新評論的項目範圍時,咱們調用一個函數來完成(使用僞代碼):

FUNCTION get_latest_comments(start,num_items): 
   id_list = redis.lrange(&quot;latest.comments&quot;,start,start+num_items-1) 
   IF id_list.length &lt; num_items 
       id_list = SQL_DB(&quot;SELECT ... ORDER BY time LIMIT ...&quot;) 
   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的變體命令,可以在列表爲空時阻塞隊列。

緩存

Redis的緩存部分值得寫一篇新文章,我這裏只是簡單的說一下。Redis可以替代memcached,讓你的緩存從只能存儲數據變得可以更新數據,所以你再也不須要每次都從新生成數據了。

Redis能夠解決你的問題!

如今你就能夠用上Redis,讓用戶感到更輕鬆,讓你的系統變得再也不復雜,讓你的網站反應更快。你不須要改變現有的數據庫結構,使用Redis給你的框架帶來新的東西,來完成那些從前認爲不可能作到/很難作到的,或是成本過高的任務。

原文地址:http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

相關文章
相關標籤/搜索