1、字符串使用場景
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次。
2、哈希使用場景
a) 緩存用戶信息
相比於使用字符串序列化緩存用戶信息，哈希類型變得更加直觀，並且在更新操作上會更加便捷。可以將每個用戶的id定義為鍵后綴，多對field-value對應每個用戶的屬性。
哈希類型和關系型數據庫不同之處：
哈希類型是稀疏的，而關系型數據庫是完全結構化的，例如哈希類型每個鍵可以有不同的field，而關系型數據庫一旦添加新的列，所有行都要為其設置值(即使為NULL)。
關系型數據庫可以做復雜的關系查詢，而Redis去模擬關系型復雜查詢開發困難，維護成本高。
三種緩存用戶信息優缺點比較：
原生字符串類型：每個屬性一個鍵
優點：簡單直觀，每個屬性都支持更新操作。
缺點：占用過多的鍵，內存占用量較大，同時用戶信息內聚性比較差，所以此種方案一般不會在生產環境使用。
序列化字符串類型：將用戶信息序列化后用一個鍵保存。
優點：簡化編程，如果合理的使用序列化可以提高內存的使用效率。
缺點：序列化和反序列化有一定的開銷，同時每次更新屬性都需要把全部數據取出進行反序列化，更新后再序列化到Redis中。
哈希類型：每個用戶屬性使用一對field-value，但是只用一個鍵保存。
優點：簡單直觀，如果使用合理可以減少內存空間的使用。
缺點：要控制哈希在ziplist和hashtable兩種內部編碼的轉換，hashtable會消耗更多內存。
3、列表使用場景
a) 消息隊列
Redis的lpush+brpop命令組合即可實現阻塞隊列，生產者客戶端使用lrpush從列表左側插入元素，多個消費者客戶端使用brpop命令阻塞式的"搶"列表尾部的元素，多個客戶端保證了消費的負載均衡和高可用性。
b) 文章列表
每個用戶有屬於自己的文章列表，現在需要分頁展示文章列表。此時可以考慮使用列表，因為列表不但是有序的，同時支持按照索引范圍獲取元素。
c) 開發提示
lpush + lpop = Stack(棧)
lpush + rpop = Queue(隊列)
lpush + ltrim = Capped Collection(有限集合)
lpush + brpop = Message Queue(消息隊列)
4、集合
a) 標簽(tag)
集合類型比較典型的使用場景是標簽(tag)，例如一個用戶可能對娛樂、體育比較感興趣，另一個用戶可能對歷史、新聞比較感興趣，這些興趣就是標簽。 開發提示：用戶和標簽的關系維護應該在一個事物執行，防止部分命令失敗造成的數據不一致。
5、有序集合
a) 排行榜系統
有序集合比較典型的使用場景就是排行榜系統，例如視頻網站需要對用戶上傳的視頻做排行榜，榜單的維度可能是多個方面的：按照時間、按照播放數量、按照獲得的贊數。