一、String(字串)
字串型別是redis最基礎的資料結構，首先鍵是字串型別，而且其他幾種結構都是在字串型別基礎上構建的，
所以字串型別能為其他四種資料結構的學習尊定基礎。
字串型別實際上可以是字串
（簡單的字串、複雜的字串（xml、json）、數字（整數、浮點數）、二進位制（圖片、音訊、視訊）），
但最大不能超過512M。

使用場景：
快取功能：字串最經典的使用場景，redis最為快取層，Mysql作為儲存層，絕大部分請求資料都是
redis中獲取，由於redis具有支撐高併發特性，所以快取通常能起到加速讀寫和降低 後端壓力的作用。
（redis為何具備支撐高併發的特性，下次文章講解）。
計數器：許多運用都會使用redis作為計數的基礎工具，他可以實現快速計數、查詢快取的功能，
同時資料可以一步落地到其他的資料來源。
如：視訊播放數系統就是使用redis作為視訊播放數計數的基礎元件。
共享session：出於負載均衡的考慮，分散式服務會將使用者資訊的訪問均衡到不同伺服器上，
使用者重新整理一次訪問可能會需要重新登入，為避免這個問題可以用redis將使用者session集中管理，
在這種模式下只要保證redis的高可用和擴充套件性的，每次獲取使用者更新或查詢登入資訊
都直接從redis中集中獲取。
限速：處於安全考慮，每次進行登入時讓使用者輸入手機驗證碼，為了簡訊介面不被頻繁訪問，
會限制使用者每分鐘獲取驗證碼的頻率。

二、Hash(雜湊)
在redis中雜湊型別是指鍵本身又是一種鍵值對結構，如 value={{field1,value1},......{fieldN,valueN}}

使用場景：
雜湊結構相對於字串序列化快取資訊更加直觀，並且在更新操作上更加便捷。
所以常常用於**使用者資訊**等管理，但是雜湊型別和關係型資料庫有所不同，雜湊型別是稀疏的，
而關係型資料庫是完全結構化的，關係型資料庫可以做複雜的關係查詢，而redis去模擬關係型複雜查詢開發困難，維護成本高。

三、List(列表)
列表型別是用來儲存多個有序的字串，列表中的每個字串成為元素（element）,一個列表最多可以儲存
2的32次方-1個元素，在redis中，可以隊列表兩端插入（pubsh）和彈出（pop），還可以獲取指定範圍的元素
列表、獲取指定索引下表的元素等，列表是一種比較靈活的資料結構，它可以充當棧和佇列的角色，
在實際開發中有很多應用場景。
優點：
1.列表的元素是有序的，這就意味著可以通過索引下標獲取某個或某個範圍內的元素列表。
2.列表內的元素是可以重複的。

使用場景：
訊息佇列： redis的lpush+brpop命令組合即可實現阻塞佇列，生產者客戶端是用lupsh從列表左側插入元素，
多個消費者客戶端使用brpop命令阻塞時的“搶”列表尾部的元素，多個客戶端保證了消費的負載均衡
和高可用性
列表類：如twitter的關注列表、粉絲列表都可以用Redis的list結構來實現

四、Set(集合)
集合型別也是用來儲存多個字串的元素，但和列表不同的是集合中不允許有重複的元素，並且集合中的元素是
無序的，不能通過索引下標獲取元素，redis除了支援集合內的增刪改查，同時還支援多個集合取交集、並集、
差集，併合理的使用好集合型別，能在實際開發中解決很多實際問題。

使用場景：
標籤（tag）：集合型別比較典型的使用場景，如一個使用者對娛樂、體育比較感興趣，另一個可能對新聞感興
趣，這些興趣就是標籤，有了這些資料就可以得到同一標籤的人，以及使用者的共同愛好的標籤，
這些資料對於使用者體驗以及曾強使用者粘度比較重要。
（使用者和標籤的關係維護應該放在一個事物內執行，防止部分命令失敗造成資料不一致）

sadd=tagging（標籤）
spop/srandmember=random item（生成隨機數，比如抽獎）
sadd+sinter=social Graph(社交需求)

五、Stored Set(有序集合)

有序集合和集合有著必然的聯絡，他保留了集合不能有重複成員的特性，但不同得是，有序集合中的元素是可以
排序的，但是它和列表的使用索引下標作為排序依據不同的是，它給每個元素設定一個分數，作為排序的依據。
（有序集合中的元素不可以重複，但是csore可以重複，就和一個班裡的同學學號不能重複，但考試成績可以相
同）。

使用場景：
排行榜：有序集合經典使用場景。例如視訊網站需要對使用者上傳的視訊做排行榜，榜單維護可能是多方面：
按照時間、按照播放量、按照獲得的贊數等。
分頁：通過ZRANGE、ZREVRANGE等命令可以實現分頁的功能