Redis在很多方面與其他數(shù)據(jù)庫解決方案不同：它使用內存提供主存儲支持，而僅使用硬盤做持久性的存儲；它的數(shù)據(jù)模型非常獨特，用的是單線程。另一個大區(qū)別在于，你可以在開發(fā)環(huán)境中使用Redis的功能，但卻不需要轉到Redis。

轉向Redis當然也是可取的，許多開發(fā)者從一開始就把Redis作為首選數(shù)據(jù)庫；但設想如果你的開發(fā)環(huán)境已經(jīng)搭建好，應用已經(jīng)在上面運行了，那么更換數(shù)據(jù)庫框架顯然不那么容易。另外在一些需要大容量數(shù)據(jù)集的應用，Redis也并不適合，因為它的數(shù)據(jù)集不會超過系統(tǒng)可用的內存。所以如果你有大數(shù)據(jù)應用，而且主要是讀取訪問模式，那么Redis并不是正確的選擇。

然而我喜歡Redis的一點就是你可以把它融入到你的系統(tǒng)中來，這就能夠解決很多問題，比如那些你現(xiàn)有的數(shù)據(jù)庫處理起來感到緩慢的任務。這些你就可以通過Redis來進行優(yōu)化，或者為應用創(chuàng)建些新的功能。在本文中，我就想探討一些怎樣將Redis加入到現(xiàn)有的環(huán)境中，并利用它的原語命令等功能來解決傳統(tǒng)環(huán)境中碰到的一些常見問題。在這些例子中，Redis都不是作為首選數(shù)據(jù)庫。

顯示最新的項目列表

下面這個語句常用來顯示最新項目，隨著數(shù)據(jù)多了，查詢毫無疑問會越來越慢。

在Web應用中，“列出最新的回復”之類的查詢非常普遍，這通常會帶來可擴展性問題。這令人沮喪，因為項目本來就是按這個順序被創(chuàng)建的，但要輸出這個順序卻不得不進行排序操作。

類似的問題就可以用Redis來解決。比如說，我們的一個Web應用想要列出用戶貼出的最新20條評論。在最新的評論邊上我們有一個“顯示全部”的鏈接，點擊后就可以獲得更多的評論。

我們假設數(shù)據(jù)庫中的每條評論都有一個唯一的遞增的ID字段。

我們可以使用分頁來制作主頁和評論頁，使用Redis的模板：

-每次新評論發(fā)表時，我們會將它的ID添加到一個Redis列表：

??? LPUSH latest.comments

-我們將列表裁剪為指定長度，因此Redis只需要保存最新的5000條評論：

??? LTRIM latest.comments 0 5000

-每次我們需要獲取最新評論的項目范圍時，我們調用一個函數(shù)來完成（使用偽代碼）：

這里我們做的很簡單。在Redis中我們的最新ID使用了常駐緩存，這是一直更新的。但是我們做了限制不能超過5000個ID，因此我們的獲取ID函數(shù)會一直詢問Redis。只有在start/count參數(shù)超出了這個范圍的時候，才需要去訪問數(shù)據(jù)庫。

我們的系統(tǒng)不會像傳統(tǒng)方式那樣“刷新”緩存，Redis實例中的信息永遠是一致的。SQL數(shù)據(jù)庫（或是硬盤上的其他類型數(shù)據(jù)庫）只是在用戶需要獲取“很遠”的數(shù)據(jù)時才會被觸發(fā)，而主頁或第一個評論頁是不會麻煩到硬盤上的數(shù)據(jù)庫了。

刪除與過濾

我們可以使用LREM來刪除評論。如果刪除操作非常少，另一個選擇是直接跳過評論條目的入口，報告說該評論已經(jīng)不存在。

有些時候你想要給不同的列表附加上不同的過濾器。如果過濾器的數(shù)量受到限制，你可以簡單的為每個不同的過濾器使用不同的Redis列表。畢竟每個列表只有5000條項目，但Redis卻能夠使用非常少的內存來處理幾百萬條項目。

排行榜相關

另一個很普遍的需求是各種數(shù)據(jù)庫的數(shù)據(jù)并非存儲在內存中，因此在按得分排序以及實時更新這些幾乎每秒鐘都需要更新的功能上數(shù)據(jù)庫的性能不夠理想。

典型的比如那些在線游戲的排行榜，比如一個Facebook的游戲，根據(jù)得分你通常想要：

-列出前100名高分選手

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

這些操作對于Redis來說小菜一碟，即使你有幾百萬個用戶，每分鐘都會有幾百萬個新的得分。

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

??? ZADD leaderboard

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

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

用戶的全球排名也相似，只需要：ZRANK leaderboard 。

按照用戶投票和時間排序

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

??? score = points / time^alpha

因此用戶的投票會相應的把新聞挖出來，但時間會按照一定的指數(shù)將新聞埋下去。下面是我們的模式，當然算法由你決定。

模式是這樣的，開始時先觀察那些可能是最新的項目，例如首頁上的1000條新聞都是候選者，因此我們先忽視掉其他的，這實現(xiàn)起來很簡單。

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

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

過期項目處理

另一種常用的項目排序是按照時間排序。我們使用unix時間作為得分即可。

模式如下：

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

- 另一項后臺任務使用ZRANGE…SCORES查詢排序集合，取出最新的10個項目。如果發(fā)現(xiàn)unix時間已經(jīng)過期，則在數(shù)據(jù)庫中刪除條目。

計數(shù)

Redis是一個很好的計數(shù)器，這要感謝INCRBY和其他相似命令。

我相信你曾許多次想要給數(shù)據(jù)庫加上新的計數(shù)器，用來獲取統(tǒng)計或顯示新信息，但是最后卻由于寫入敏感而不得不放棄它們。

好了，現(xiàn)在使用Redis就不需要再擔心了。有了原子遞增（atomic increment），你可以放心的加上各種計數(shù)，用GETSET重置，或者是讓它們過期。

例如這樣操作：

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

特定時間內的特定項目

另一項對于其他數(shù)據(jù)庫很難，但Redis做起來卻輕而易舉的事就是統(tǒng)計在某段特點時間里有多少特定用戶訪問了某個特定資源。比如我想要知道某些特定的注冊用戶或IP地址，他們到底有多少訪問了某篇文章。

每次我獲得一次新的頁面瀏覽時我只需要這樣做：

??? SADD page:day1:

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

想知道特定用戶的數(shù)量嗎？只需要使用SCARD page:day1:。

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

實時分析正在發(fā)生的情況，用于數(shù)據(jù)統(tǒng)計與防止垃圾郵件等

我們只做了幾個例子，但如果你研究Redis的命令集，并且組合一下，就能獲得大量的實時分析方法，有效而且非常省力。使用Redis原語命令，更容易實施垃圾郵件過濾系統(tǒng)或其他實時跟蹤系統(tǒng)。

Pub/Sub

Redis的Pub/Sub非常非常簡單，運行穩(wěn)定并且快速。支持模式匹配，能夠實時訂閱與取消頻道。

隊列

你應該已經(jīng)注意到像list push和list pop這樣的Redis命令能夠很方便的執(zhí)行隊列操作了，但能做的可不止這些：比如Redis還有l(wèi)ist pop的變體命令，能夠在列表為空時阻塞隊列。

緩存

Redis的緩存部分值得寫一篇新文章，我這里只是簡單的說一下。Redis能夠替代memcached，讓你的緩存從只能存儲數(shù)據(jù)變得能夠更新數(shù)據(jù)，因此你不再需要每次都重新生成數(shù)據(jù)了。

Redis可以解決你的問題！

現(xiàn)在你就可以用上Redis，讓用戶感到更輕松，讓你的系統(tǒng)變得不再復雜，讓你的網(wǎng)站反應更快。你不需要改變現(xiàn)有的數(shù)據(jù)庫結構，使用Redis給你的框架帶來新的東西，來完成那些從前認為不可能做到/很難做到的，或是成本太高的任務。

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