Redis的特點及應用場景有哪些

本篇內容介紹了“Redis的特點及應用場景有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Redis的特點：

Redis 與其他 key - value 緩存產品有以下三個特點：

• Redis支持數據的持久化，可以將內存中的數據保存在磁盤中，重啟的時候可以再次加載進行使用。

• Redis不僅僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。

• Redis支持數據的備份，即master-slave模式的數據備份。

Redis的優勢：

• 性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 。

• 豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。

• 原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全并后的原子性執行。

• 豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。

Redis與其他key-value存儲有什么不同？

• 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

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

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數據庫（或是硬盤上的其他類型數據庫）只是在用戶需要獲取“很遠”的數據時才會被觸發，而主頁或第一個評論頁是不會麻煩到硬盤上的數據庫了。

2. 刪除與過濾

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

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

3. 排行榜相關

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

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

• 列出前100名高分選手

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

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

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

ZADD leaderboard

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

得到前100名高分用戶很簡單：

ZREVRANGE leaderboard 0 99

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

ZRANK leaderboard

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: EXPIRE 
user: 60

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

7. 特定時間內的特定項目

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

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

SADD page:day1:<page_id> <user_id>

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

想知道特定用戶的數量嗎？只需要使用

SCARD page:day1:<page_id>

需要測試某個特定用戶是否訪問了這個頁面？

8. 實時分析正在發生的情況，用于數據統計與防止垃圾郵件等

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

9. Pub/Sub

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

10. 隊列

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

11. 緩存

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

“Redis的特點及應用場景有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！