轉載: 


    Redis在很多方面與其他資料庫解決方案不同：它使用記憶體提供主儲存支援，而僅使用硬碟做永續性的儲存；它的資料模型非常獨特，用的是單執行緒。另一個大區別在於，你可以在開發環境中使用Redis的功能，但卻不需要轉到Redis。
    轉向Redis當然也是可取的，許多開發者從一開始就把Redis作為首選資料庫；但設想如果你的開發環境已經搭建好，應用已經在上面執行了，那麼更換資料庫框架顯然不那麼容易。另外在一些需要大容量資料集的應用，Redis也並不適合，因為它的資料集不會超過系統可用的記憶體。所以如果你有大資料應用，而且主要是讀取訪問模式，那麼Redis並不是正確的選擇。
    然而我喜歡Redis的一點就是你可以把它融入到你的系統中來，這就能夠解決很多問題，比如那些你現有的資料庫處理起來感到緩慢的任務。這些你就可以透過Redis來進行最佳化，或者為應用建立些新的功能。在本文中，我就想探討一些怎樣將Redis加入到現有的環境中，並利用它的原語命令等功能來解決 傳統環境中碰到的一些常見問題。在這些例子中，Redis都不是作為首選資料庫。

1、顯示最新的專案列表

下面這個語句常用來顯示最新專案，隨著資料多了，查詢毫無疑問會越來越慢。
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 
       每次我們需要獲取最新評論的專案範圍時，我們呼叫一個函式來完成（使用虛擬碼）：


      這裡我們做的很簡單。在Redis中我們的最新ID使用了常駐快取，這是一直更新的。但是我們做了限制不能超過5000個ID，因此我們的獲取ID函式會一直詢問Redis。只有在start/count引數超出了這個範圍的時候，才需要去訪問資料庫。
        我們的系統不會像傳統方式那樣“重新整理”快取，Redis例項中的資訊永遠是一致的。SQL資料庫（或是硬碟上的其他型別資料庫）只是在使用者需要獲取“很遠”的資料時才會被觸發，而主頁或第一個評論頁是不會麻煩到硬碟上的資料庫了。

2、刪除與過濾

      我們可以使用LREM來刪除評論。如果刪除操作非常少，另一個選擇是直接跳過評論條目的入口，報告說該評論已經不存在。
       有些時候你想要給不同的列表附加上不同的過濾器。如果過濾器的數量受到限制，你可以簡單的為每個不同的過濾器使用不同的Redis列表。畢竟每個列表只有5000條專案，但Redis卻能夠使用非常少的記憶體來處理幾百萬條專案。

3、排行榜相關

      另一個很普遍的需求是各種資料庫的資料並非儲存在記憶體中，因此在按得分排序以及實時更新這些幾乎每秒鐘都需要更新的功能上資料庫的效能不夠理想。
      典型的比如那些線上遊戲的排行榜，比如一個Facebook的遊戲，根據得分你通常想要：
         - 列出前100名高分選手
         - 列出某使用者當前的全球排名

      這些操作對於Redis來說小菜一碟，即使你有幾百萬個使用者，每分鐘都會有幾百萬個新的得分。
      模式是這樣的，每次獲得新得分時： ZADD leaderboard  <score>  <username> ，可能用userID來取代username，這取決於你是怎麼設計的。
      得到前100名高分使用者很簡單：        ZREVRANGE leaderboard 0 99。
      使用者的全球排名也相似，只需要：   ZRANK leaderboard <username>。

4、按照使用者投票和時間排序
      排行榜的一種常見變體模式就像Reddit或Hacker News用的那樣，新聞按照類似下面的公式根據得分來排序：   score = points / time^alpha 
      因此使用者的投票會相應的把新聞挖出來，但時間會按照一定的指數將新聞埋下去。下面是我們的模式，當然演算法由你決定。
      模式是這樣的，開始時先觀察那些可能是最新的專案，例如首頁上的1000條新聞都是候選者，因此我們先忽視掉其他的，這實現起來很簡單。
      每次新的新聞貼上來後，我們將ID新增到列表中，使用LPUSH + LTRIM，確保只取出最新的1000條專案。
      有一項後臺任務獲取這個列表，並且持續的計算這1000條新聞中每條新聞的最終得分。計算結果由ZADD命令按照新的順序填充生成列表，老新聞則被清除。這裡的關鍵思路是排序工作是由後臺任務來完成的。

5、處理過期專案

      另一種常用的專案排序是按照時間排序。我們使用unix時間作為得分即可。
      模式如下：
       - 每次有新專案新增到我們的非Redis資料庫時，我們把它加入到排序集合中。這時我們用的是時間屬性，current_time和time_to_live。
       - 另一項後臺任務使用ZRANGE…SCORES查詢排序集合，取出最新的10個專案。如果發現unix時間已經過期，則在資料庫中刪除條目。

6、計數

       Redis是一個很好的計數器，這要感謝INCRBY和其他相似命令。
       我相信你曾許多次想要給資料庫加上新的計數器，用來獲取統計或顯示新資訊，但是最後卻由於寫入敏感而不得不放棄它們。
       好了，現在使用Redis就不需要再擔心了。有了原子遞增（atomic increment），你可以放心的加上各種計數，用GETSET重置，或者是讓它們過期。
       例如這樣操作：
         INCR user:<id> EXPIRE 
         user:<id> 60 
       你可以計算出最近使用者在頁面間停頓不超過60秒的頁面瀏覽量，當計數達到比如20時，就可以顯示出某些條幅提示，或是其它你想顯示的東西。

7、特定時間內的特定專案

        另一項對於其他資料庫很難，但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>。

8、實時分析正在發生的情況，用於資料統計與防止垃圾郵件等

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

9、Pub/Sub

       Redis的Pub/Sub非常非常簡單，執行穩定並且快速。支援模式匹配，能夠實時訂閱與取消頻道。

10、佇列

        你應該已經注意到像list push和list pop這樣的Redis命令能夠很方便的執行佇列操作了，但能做的可不止這些：比如Redis還有list pop的變體命令，能夠在列表為空時阻塞佇列。
       現代的網際網路應用大量地使用了訊息佇列（Messaging）。訊息佇列不僅被用於系統內部元件之間的通訊，同時也被用於系統跟其它服務之間的互動。訊息佇列的使用可以增加系統的可擴充套件性、靈活性和使用者體驗。非基於訊息佇列的系統，其執行速度取決於系統中最慢的元件的速度（注：短板效應）。而基於訊息佇列可以將系統中各元件解除耦合，這樣系統就不再受最慢元件的束縛，各元件可以非同步執行從而得以更快的速度完成各自的工作。
    此外，當伺服器處在高併發操作的時候，比如頻繁地寫入日誌檔案。可以利用訊息佇列實現非同步處理。從而實現高效能的併發操作。

11、快取

        Redis的快取部分值得寫一篇新文章，我這裡只是簡單的說一下。Redis能夠替代memcached，讓你的快取從只能儲存資料變得能夠更新資料，因此你不再需要每次都重新生成資料了。