Redis作為當今最流行的記憶體資料庫,已經成為服務端加速的必備工具之一。對於Redis為什麼那麼快?以及Redis採用單線程,但為什麼反而獲得更高的性能的疑問,在之前的Redis為什麼那麼快?一文中,已經有所介紹。 今天通過這篇,我們來瞭解一下Redis最常見的5種應用場景。您可以通過視頻來學習,如 ...
Redis作為當今最流行的記憶體資料庫,已經成為服務端加速的必備工具之一。對於Redis為什麼那麼快?以及Redis採用單線程,但為什麼反而獲得更高的性能的疑問,在之前的Redis為什麼那麼快?一文中,已經有所介紹。
今天通過這篇,我們來瞭解一下Redis最常見的5種應用場景。您可以通過視頻來學習,如果您不方便觀看視頻,也可以通過文字內容學習,文字部分做了更概要的總結。
緩存(Cache)
Redis的第一個應用場景是Redis作為緩存對象來加速Web應用的訪問。
在該場景下,有一些存儲於資料庫中的數據會被頻繁訪問,如果頻繁的訪問資料庫,資料庫負載會升高,同時由於資料庫IO比較慢,應用程式的響應會比較差。此時,如果引入Redis來存儲這些被頻繁訪問的數據,就可以有效的降低資料庫的負載,同時提高應用程式的請求響應。
會話存儲(Session)
使用Redis來存儲會話(Session)數據,可以實現在無狀態的伺服器之間共用用戶相關的狀態數據數據。
當用戶登錄Web應用時候,將會話數據存儲於Redis,並將唯一的會話ID(Session ID)返回到客戶端的Cookie中。當用戶再嚮應用發送請求時,會將此會話ID包含在請求中。無狀態的Web伺服器,根據這個會話ID從Redis中搜索相關的會話數據來進一步請求處理。
這裡需要註意的是,Redis是記憶體資料庫,如果採用單實例部署。那麼當Redis伺服器故障重啟之後,所有的Session會話會消失,用戶不得不重新登錄來獲取新的Session。所以,當拿Redis來存儲Session的時候,建議採用主從的集群模式來部署。這樣,即使主伺服器掛了,馬上有從庫接管流量,不影響用戶的使用。
分散式鎖(Distributed Lock)
當我們在應用中部署了多個節點,這些節點需要操作同一個資源的時候會存在競爭。此時,我們可以使用Redis來作為分散式鎖,以協調多個節點對共用資源的操作。
這裡主要是用Redis的原子操作命令:SETNX
,該命令僅允許key不存在的時候才能設置key。
下圖展示了一個簡單用例。Client 1通過SETNX
命令嘗試創建lock 1234abcd
。如果當前還沒有這個key,那麼將返回1。Client 1獲得鎖,就可以執行對共用資源的操作,操作完成之後,刪除剛剛創建的lock(釋放分散式鎖)。如果Client 1在執行SETNX
命令的時候,返回了0,說明有其他客戶端占用了這key,那麼等待一段時間(等其他節點釋放)之後再嘗試。
上面這個簡單實現雖然可以滿足很多用例,但它並不具備良好的容錯機制。如果要在生產上是用的話,更推薦採用一些更高質量的分散式鎖實現。比如,Java平臺的話,可以選擇:Redisson.
速率限制器(Rate Limiter)
由於Redis提供了計數器功能,所以我們可以通過該能力,配合超時時間,來實現速率限制器,最常見的場景就是服務端是用的請求限流。
一個基本的限速實現如下圖:
根據用戶id或者ip來作為key,使用INCR
命令來記錄用戶的請求數量。然後將該請求數量與允許的請求上限數量做比較,只有低於限制的時候,才會執行請求處理。如果超過限制,就拒絕請求。
同時,請求數量的計數器需要設置一個時間視窗,比如:1分鐘。也就是沒過一分鐘時間,計數器將被清零,重新計數。所以,當一個時間視窗中被限流之後,等到下一個時間視窗,就能恢復繼續請求。以實現限制速率的效果。
除了時間窗演算法之外,漏桶演算法也能通過Redis來實現。
排行榜(Rank/Leaderboard)
由於Redis提供了排序集合(Sorted Sets)的功能,所以很多游戲應用採用Redis來實現各種排行榜功能。
排序集合是唯一元素(比如:用戶id)的集合,每個元素按分數排序,這樣可以快速的按分數來檢索元素
小結
Redis的應用非常廣泛,這裡僅總結了一些常見的用法。除此之外,還有很多有意思的應用,這取決於業務場景。大家可以舉一反三。
如果您平時也有上油管看前沿視頻的話也可以裝一個Youtube中文配音,它可以有效地提高學習效率。如果您因為網路原因不方便查看這些內容,也可以關註我的視頻號「程式猿DD」或者B站頻道,我會經常分享一些日常看到的精華學習資料,感興趣的小伙伴根據自己平時習慣選擇訂閱即可。
歡迎關註我的公眾號:程式猿DD。第一時間瞭解前沿行業消息、分享深度技術乾貨、獲取優質學習資源