Redis字符串類型使用場景

在上一篇中咱們詳細介紹了Redis字符串類型的相關命令及內部編碼，在這一篇中，咱們將經過上一篇的學習來了解一下在平常的開發中使用Redis的字符串類型，能夠解決咱們什麼問題？

---

使用場景

---

一. 緩存功能

咱們作開發時，都知道，項目中的全部的數據都是從存儲層獲取的，也就是數據庫中。但若是全部的請求都從數據庫中獲取，會致使系統有很大的壓力，由於直接從數據庫中獲取數據，會涉及到數據庫中讀寫操做，而數據庫中讀寫操做是會耗費系統資源的。因此對於大部分公司來講，系統的架構中都會添加一個緩存層，大部分的請求數據都會先從緩存層中獲取，若是緩存層中沒有查到數據，在從存儲層獲取，也就是數據庫中。而後在將存儲層獲取到的數據同步到緩存層中。這樣一來，對於大部分請求來講都會從緩存層中查找到，這樣就大大下降了存儲層的壓力。而緩存層Redis是一種解決方案之一。下面咱們簡單模擬一下用戶請求數據的過程。

---

二. 計數

計數功能在不少網站中都比較常見，最典型的就是頁面的播放量。對於一個視頻網站來講，因爲訪問的人數較多，若是每次有人訪問，都直接修改數據庫的話，那這種大併發量而且頻繁的修改數據庫的話，必定會對數據庫形成較大的壓力，極端狀況下可能會致使數據庫宕機等，而且因爲訪問量較大，咱們在開發時，還要考慮多線程的兼容問題，不然會形成數據的不許確。除此以外，因爲訪問量很大，也會形成每一個用戶請求返回的時間變長，用戶訪問網站時，可能會顯示遲鈍等。而用Redis則不會出現這種狀況。首先Redis是將數據保存到內存中的，相比數據庫的磁盤IO操做，性能提高較明顯。其次Redis是單線程架構，咱們不用爲大併發，而作特殊的多線程處理。其三就是Redis提供了不少支持原子性操做的命令，咱們能夠直接使用，而不用考慮相關細節。因此用Redis來實現網站或者其它業務的計數功能是比較合適的。但有一點要特別注意，咱們將計數的數據保存在Redis中是爲了避免頻繁的執行數據庫的修改操做。而數據的最終結果仍是要保存在數據庫中的（雖然Redis有持久化功能）。因此咱們在實際的開發中，能夠選擇某個時間點，在將Redis中的計數數據同步到數據庫中，大多數都會採用定時調度的方式，來同步數據，固然也能夠考慮其它的計數實現。

---

三. 共享Session

咱們知道在項目開發中Session中保存着用戶的登陸信息，當用戶訪問系統時首先判斷該用戶的Session中有沒有該用戶的信息，固然還要判斷是否超過了Session失效時間。若是有則認爲用戶已經成功登陸過，因此容許訪問，反之，則提示用戶登陸，或者直接跳轉到登陸。在單一的架構中，上述場景是沒有問題的，可是在分佈式架構中上述場景就有問題了。咱們知道Session是保存在服務端的，也就是說，咱們的服務端部署在哪臺機器上，Session就保存在哪臺機器上。而分佈式的方式是將服務端部署到了多臺機器上。這就會致使一個問題，雖然用戶登陸成功了，可是因爲負載均衡等緣由，給用戶提供服務的服務端和給用戶登陸的服務端，不在一臺機器上，這樣就會出現，雖然用戶登陸成功了，可是咱們仍是會提示用戶沒有登陸。由於除了用戶登陸那臺機器有用戶Session信息外，其它的機器沒有用戶的Session信息，因此會出現上述狀況。也就是以下圖所示的那樣：

既然上述的場景在分佈式中有問題，那我就要想辦法解決它。解決的方式有不少種，在這裏，只介紹一種解決方案，也就是採用Redis解決。當用戶登陸成功時，咱們不在將Session信息保存到本地的服務器中，而是將它保存到Redis中。這樣不管哪一個服務器先登陸成功，對於用戶的Session信息只有一份，也就是保存到Redis中的那一份。這樣，當其它服務器判斷用戶是否登陸時，都從Redis中獲取Session信息。若是Redis中有用戶的Session信息，而用戶必定登陸成功過。不然，而用戶未登陸過，或者登陸失敗。這樣就解決了，分佈式用戶登陸的問題。也就是以下圖所示：

---

上述這些都是Redis中字符串類型的使用場景，但在實際開發中使用場景遠遠不僅這些。只要咱們熟練的使用Redis中字符串類型的相關命令，就能夠解決咱們開發中不少複雜的問題。

---

• 原文地址：http://jilinwula.com/article/...