Redis使用場景

一、字符串使用場景

    a) 緩存功能

        典型使用場景：Redis做爲緩存層，MySQL做爲存儲層，絕大部分請求的數據都是從Redis中獲取，因爲Redis具備支撐高併發的特性，因此緩存一般能起到加速讀寫和下降後端壓力的做用。

        開發提示：與MySQL等關係型數據庫不一樣的是，Redis沒有命令空間，並且也沒有對鍵名有強制要求，但設計合理的鍵名，有利於防止鍵衝突和項目的可維護性，比較推薦的方式是使用「業務名:對象名:id:[屬性]」做爲鍵名。例如MySQL的數據庫名爲vs，用戶表名爲user，那麼對應的鍵能夠用"vs:user:1"，"vs:user:1:name"來表示，若是當前Redis只被一個業務使用，甚至能夠去掉vs。若是鍵名比較長，例如"user:{uid}:friends:message:{mid}"，能夠在能描述含義的前提下適當減小鍵的長度，例如採用縮寫形式，從而減小因爲鍵過長的內存浪費。

    b) 計數

        典型應用場景：視頻播放數計數的基礎組件，用戶每播放一次視頻，相應的視頻播放數就會自增1。Redis能夠實現快速計數、查詢緩存的功能，同時數據能夠異步落地到其餘數據源。

        開發提示：實際上一個真實的計數系統要考慮的問題會不少，防做弊、按照不一樣維度計數，數據持久化到底層數據源等。

    c) 共享Session

        典型應用場景：用戶登錄信息，Redis將用戶的Session進行集中管理，每次用戶更新或查詢登錄信息都直接從Redis中集中獲取。

    d) 限速

        典型應用場景：驗證碼接口訪問頻率限制，用戶登錄時須要讓用戶輸入手機驗證碼，從而肯定是不是用戶本人，可是爲了短信接口不被頻繁訪問，會限制用戶每分鐘獲取驗證碼的頻率，例如一分鐘不能超過5次。

 

二、哈希使用場景

    a) 緩存用戶信息

        相比於使用字符串序列化緩存用戶信息，哈希類型變得更加直觀，而且在更新操做上會更加便捷。能夠將每一個用戶的id定義爲鍵後綴，多對field-value對應每一個用戶的屬性。

        哈希類型和關係型數據庫不一樣之處：

              哈希類型是稀疏的，而關係型數據庫是徹底結構化的，例如哈希類型每一個鍵能夠有不一樣的field，而關係型數據庫一旦添加新的列，全部行都要爲其設置值(即便爲NULL)。

              關係型數據庫能夠作複雜的關係查詢，而Redis去模擬關係型複雜查詢開發困難，維護成本高。

        三種緩存用戶信息優缺點比較：

              原生字符串類型：每一個屬性一個鍵

                   優勢：簡單直觀，每一個屬性都支持更新操做。

                   缺點：佔用過多的鍵，內存佔用量較大，同時用戶信息內聚性比較差，因此此種方案通常不會在生產環境使用。

             序列化字符串類型：將用戶信息序列化後用一個鍵保存。

                  優勢：簡化編程，若是合理的使用序列化能夠提升內存的使用效率。

                  缺點：序列化和反序列化有必定的開銷，同時每次更新屬性都須要把所有數據取出進行反序列化，更新後再序列化到Redis中。

             哈希類型：每一個用戶屬性使用一對field-value，可是隻用一個鍵保存。

                  優勢：簡單直觀，若是使用合理能夠減小內存空間的使用。

                  缺點：要控制哈希在ziplist和hashtable兩種內部編碼的轉換，hashtable會消耗更多內存。

 

三、列表使用場景

    a) 消息隊列

        Redis的lpush+brpop命令組合便可實現阻塞隊列，生產者客戶端使用lrpush從列表左側插入元素，多個消費者客戶端使用brpop命令阻塞式的"搶"列表尾部的元素，多個客戶端保證了消費的負載均衡和高可用性。

    b) 文章列表

        每一個用戶有屬於本身的文章列表，如今須要分頁展現文章列表。此時能夠考慮使用列表，由於列表不可是有序的，同時支持按照索引範圍獲取元素。

    c) 開發提示

        lpush + lpop = Stack(棧)

        lpush + rpop = Queue(隊列)

        lpush + ltrim = Capped Collection(有限集合)

        lpush + brpop = Message Queue(消息隊列)

 

四、集合

    a) 標籤(tag)

        集合類型比較典型的使用場景是標籤(tag)，例如一個用戶可能對娛樂、體育比較感興趣，另外一個用戶可能對歷史、新聞比較感興趣，這些興趣就是標籤。 開發提示：用戶和標籤的關係維護應該在一個事物執行，防止部分命令失敗形成的數據不一致。

 

五、有序集合

    a) 排行榜系統

        有序集合比較典型的使用場景就是排行榜系統，例如視頻網站須要對用戶上傳的視頻作排行榜，榜單的維度多是多個方面的：按照時間、按照播放數量、按照得到的贊數。