Open aszx87410 opened 5 years ago
Redis 是一個 in-memory 的 key-value database,因此常常被用在需要快取(Cache)一些資料的場合,可以減輕許多後端資料庫的壓力。這篇就來簡單介紹一下 Redis 提供哪些好用的東西,以及可以應用在什麼地方。
Redis 的官網列出了支援的每一條指令,我們先來看看最簡單的:
redis> SET mykey "Hello" redis> GET mykey "Hello"
前面有提到說 Redis 是一個 key-value pair 的資料庫,因此最簡單的 SET 就是設定某個 key 的值是多少,要取出來的話就用 GET 就好。
redis> SET mykey "10" redis> DECR mykey (integer) 9 redis> INCR mykey (integer) 10
顧名思義就是針對某個 key 加一或減一的意思,像是程式語言裡面的mykey++跟mykey--。 還有 INCRBY 與 DECRBY,可以指定你要加減的數量是多少。
mykey++
mykey--
INCRBY
DECRBY
redis> HSET mydata name "nick" redis> HSET mydata nickname "nicknick" redis> HGET mydata name "nick"
H 就是 Hashmap 的意思,所以你可以存取一個 value 底下的 field,讓你可以更多元的使用,例如說你可以定義 key 的規則是:POST + 文章 id,裡面就可以存這篇文章的讚數、回覆數等等,就不用每一次都去 Database 裡面重新抓取。
redis> SADD myset "nick" redis> SADD myset "peter" redis> SADD myset "nick" redis> SCARD myset (integer) 2
SADD 的 S 就是 Set 的意思,這邊的 Set 指的是資料結構學過的那個 Set,裡面不會有重複的內容。
Set
redis> LPUSH mylist "a" redis> LPUSH mylist "b" redis> RPUSH mylist "c" redis> LRANGE mylist 0 -1 1) "b" 2) "a" 3) "c" redis> LSET mylist 0 "d" redis> LRANGE mylist 0 -1 1) "d" 2) "a" 3) "c"
這邊的資料結構是 List,你可以選擇從左邊或是右邊 push 值進去,對應到的指令就是 LPUSH 與 RPUSH,LSET 則是指定某個 index 的 value 是多少。
List
LPUSH
RPUSH
LSET
LRANGE 可以印出指定範圍的值,支援-1這種形式,表示最後一個值。
LRANGE
-1
Redis 好用的地方就在於速度很快,所以若是開發上碰到一些場合需要速度很快的話,你可以先考慮看看 Redis 是不是能夠幫助到你,以下就舉幾個我實際使用過的例子。
其實短網址的原理非常簡單,就是一個 hash 對應到一個網址,hash 是用隨機產生,幾碼或是要有什麼符號可以自己決定,接著就把這組對應關係存到資料庫裡面,別人 query 相應的 key 時,你就 redirect 到相應的網址去就好了。
也因為是這種 key-value 的一對一關係,所以非常適合使用 Redis。 如果你不用像是 Redis 這種的 key-value cache,就必須「每一次」都從 Database 去 query。若是資料量小還好,但資料量一變大的時候,時間一定會增加,資料庫的負荷也會增加,因此在資料庫跟邏輯層之間引進一層快取,我認為是很好的選擇。
實作的過程也很簡單,
若是你的資料有超級多筆,又不想花很多的錢準備一台記憶體很大的 Redis Server(資料庫是用硬碟儲存,Redis 是存在記憶體,以儲存成本來說,資料庫會便宜許多),你可以使用 Redis 的 Expire 這個功能。
Expire
當你在儲存資料的時候,你可以新增一個 Expire time 的參數,當這個時間一到之後,這個 key 就會自動被清除。舉例來說,短網址的 expire 可以設定成 7 天,當某個網址 7 天內都沒有被任何使用者訪問的話,就會自動被刪除。
Expire time
這樣的好處是你可以減少記憶體的使用量,只保持某些「熱資料」會存在 Redis,其他比較冷門、不常被訪問的數據,就存在 Database,等到被訪問的時候再寫到 Redis 即可。
其實上面講到的短網址服務,除了縮網址這個功能,還有另一個重點,那就是:統計資料。例如說 Google 短網址,會提供給你:造訪次數、圖表、用什麼裝置等等,這些才是短網址服務的核心。
如果要做這個功能,那你勢必要記錄每一次 Request,或至少要把 Request 的內容(用什麼手機、時間點、IP)記錄下來,才有數據可以給使用者看。
存在 Database,讀取也是每次都從 Database 讀的話,就會造成一些效能上的 issue,例如說每次 refresh 統計頁面,你就必須重新:select conut(*) from short_url where id="abc123"一次,才能抓到總共有多少人造訪。
select conut(*) from short_url where id="abc123"
還記得我們提過的 INCR 嗎?這不是就派上用場了!可以自己定義 key 的格式,例如說:abc123:visit 代表 abc123 這個短網址的總共造訪次數,接著,只要在每一次的 Request 都執行:INCR abc123:visit,這個 key 裡面就是你要的數字了,以後都從 Redis 讀取就好。
INCR
INCR abc123:visit
除了這個以外,假設你想要提供「不重複 IP 訪問次數」,前面提到的 Set 就很適合。可以把每一個 Request 的來源 IP 都丟進一個 Set,只要用 SCARD 就可以知道有多少不重複 IP 了,很方便對吧!
SCARD
我曾經做過一個專案,需求如下:
可以先想一下有哪些地方會需要跟資料庫溝通
由於這個活動只有前 300 名有獎品,預估使用者有 10000 人的話,可能在 10 秒內這個活動就結束了!
10 秒內你的資料庫必須「同時承受」這麼多個 query,可能會有點吃不消,而且仔細檢視之後,會發現很多地方其實沒有必要用資料庫來做,或者是說,用 Redis 來做會更好!
例如說,可以這樣規劃:
上面的流程就可以改寫成:
原本需要三個對資料庫的操作,現在縮減到只剩下最必要的一個,其他都可以交給 Redis 處理。而且又因為 Redis 是 in-memory 的資料庫,反應速度非常快!再加上我們的 key 並不多(一萬多個 key 而已),用到的記憶體很少。
就這樣,透過 Redis 的幫助,很順利的就可以解決原本資料庫負載太重可能會很慢甚至掛掉的問題。
若是下次你有些專案使用者很多,或是需要很快速的返回資訊,但是又怕資料庫撐不住,不妨想想是不是能夠導入 Redis,或其他也是做快取的 service。其實在很多場合,如果快取運用得宜的話,可以減輕很多資料庫的負擔,同時也加快響應的速度。
若是你對 Redis 很有興趣,可以參考 Redis 設計與實現 這個網站。
前言
Redis 是一個 in-memory 的 key-value database,因此常常被用在需要快取(Cache)一些資料的場合,可以減輕許多後端資料庫的壓力。這篇就來簡單介紹一下 Redis 提供哪些好用的東西,以及可以應用在什麼地方。
常用指令
Redis 的官網列出了支援的每一條指令,我們先來看看最簡單的:
SET, GET
前面有提到說 Redis 是一個 key-value pair 的資料庫,因此最簡單的 SET 就是設定某個 key 的值是多少,要取出來的話就用 GET 就好。
INCR, DECR
顧名思義就是針對某個 key 加一或減一的意思,像是程式語言裡面的
mykey++
跟mykey--
。還有
INCRBY
與DECRBY
,可以指定你要加減的數量是多少。HSET, HGET
H 就是 Hashmap 的意思,所以你可以存取一個 value 底下的 field,讓你可以更多元的使用,例如說你可以定義 key 的規則是:POST + 文章 id,裡面就可以存這篇文章的讚數、回覆數等等,就不用每一次都去 Database 裡面重新抓取。
SADD, SCARD
SADD 的 S 就是
Set
的意思,這邊的Set
指的是資料結構學過的那個Set
,裡面不會有重複的內容。LPUSH, RPUSH, LSET, LRANGE
這邊的資料結構是
List
,你可以選擇從左邊或是右邊 push 值進去,對應到的指令就是LPUSH
與RPUSH
,LSET
則是指定某個 index 的 value 是多少。LRANGE
可以印出指定範圍的值,支援-1
這種形式,表示最後一個值。實際應用
Redis 好用的地方就在於速度很快,所以若是開發上碰到一些場合需要速度很快的話,你可以先考慮看看 Redis 是不是能夠幫助到你,以下就舉幾個我實際使用過的例子。
短網址系統
其實短網址的原理非常簡單,就是一個 hash 對應到一個網址,hash 是用隨機產生,幾碼或是要有什麼符號可以自己決定,接著就把這組對應關係存到資料庫裡面,別人 query 相應的 key 時,你就 redirect 到相應的網址去就好了。
也因為是這種 key-value 的一對一關係,所以非常適合使用 Redis。
如果你不用像是 Redis 這種的 key-value cache,就必須「每一次」都從 Database 去 query。若是資料量小還好,但資料量一變大的時候,時間一定會增加,資料庫的負荷也會增加,因此在資料庫跟邏輯層之間引進一層快取,我認為是很好的選擇。
實作的過程也很簡單,
若是你的資料有超級多筆,又不想花很多的錢準備一台記憶體很大的 Redis Server(資料庫是用硬碟儲存,Redis 是存在記憶體,以儲存成本來說,資料庫會便宜許多),你可以使用 Redis 的
Expire
這個功能。當你在儲存資料的時候,你可以新增一個
Expire time
的參數,當這個時間一到之後,這個 key 就會自動被清除。舉例來說,短網址的 expire 可以設定成 7 天,當某個網址 7 天內都沒有被任何使用者訪問的話,就會自動被刪除。這樣的好處是你可以減少記憶體的使用量,只保持某些「熱資料」會存在 Redis,其他比較冷門、不常被訪問的數據,就存在 Database,等到被訪問的時候再寫到 Redis 即可。
統計系統
其實上面講到的短網址服務,除了縮網址這個功能,還有另一個重點,那就是:統計資料。例如說 Google 短網址,會提供給你:造訪次數、圖表、用什麼裝置等等,這些才是短網址服務的核心。
如果要做這個功能,那你勢必要記錄每一次 Request,或至少要把 Request 的內容(用什麼手機、時間點、IP)記錄下來,才有數據可以給使用者看。
存在 Database,讀取也是每次都從 Database 讀的話,就會造成一些效能上的 issue,例如說每次 refresh 統計頁面,你就必須重新:
select conut(*) from short_url where id="abc123"
一次,才能抓到總共有多少人造訪。還記得我們提過的
INCR
嗎?這不是就派上用場了!可以自己定義 key 的格式,例如說:abc123:visit 代表 abc123 這個短網址的總共造訪次數,接著,只要在每一次的 Request 都執行:INCR abc123:visit
,這個 key 裡面就是你要的數字了,以後都從 Redis 讀取就好。除了這個以外,假設你想要提供「不重複 IP 訪問次數」,前面提到的
Set
就很適合。可以把每一個 Request 的來源 IP 都丟進一個 Set,只要用SCARD
就可以知道有多少不重複 IP 了,很方便對吧!高即時性排名系統
我曾經做過一個專案,需求如下:
可以先想一下有哪些地方會需要跟資料庫溝通
由於這個活動只有前 300 名有獎品,預估使用者有 10000 人的話,可能在 10 秒內這個活動就結束了!
10 秒內你的資料庫必須「同時承受」這麼多個 query,可能會有點吃不消,而且仔細檢視之後,會發現很多地方其實沒有必要用資料庫來做,或者是說,用 Redis 來做會更好!
例如說,可以這樣規劃:
上面的流程就可以改寫成:
原本需要三個對資料庫的操作,現在縮減到只剩下最必要的一個,其他都可以交給 Redis 處理。而且又因為 Redis 是 in-memory 的資料庫,反應速度非常快!再加上我們的 key 並不多(一萬多個 key 而已),用到的記憶體很少。
就這樣,透過 Redis 的幫助,很順利的就可以解決原本資料庫負載太重可能會很慢甚至掛掉的問題。
總結
若是下次你有些專案使用者很多,或是需要很快速的返回資訊,但是又怕資料庫撐不住,不妨想想是不是能夠導入 Redis,或其他也是做快取的 service。其實在很多場合,如果快取運用得宜的話,可以減輕很多資料庫的負擔,同時也加快響應的速度。
若是你對 Redis 很有興趣,可以參考 Redis 設計與實現 這個網站。