redis是一種高階的key:value儲存系統，其中value支援五種資料型別：

1.字串（string）
2.字串列表（list）
3.字串集合（set）
4.有序字串集合（sorted set）
5.雜湊（hashe）

而關於key，有幾個點要提醒大家：

1.key不要太長，儘量不要超過1024位元組，這不僅消耗記憶體，而且會降低查詢的效率；
2.key也不要太短，太短的話，key的可讀性會降低；

3.在一個專案中，key最好使用統一的命名模式，例如user:10000:passwd。

一、String

1、key/ value 儲存

2、既可以完全實現目前 Memcached 的功能，並且效率更高；

3、可以享受Redis的定時持久化，操作日誌及 Replication等功能。除了提供與 Memcached 一樣的get、set、incr、decr 等操作外，Redis還提供了下面一些操作：

• 獲取字串長度
• 往字串append內容
• 設定和獲取字串的某一段內容
• 設定及獲取字串的某一位（bit）
• 批量設定一系列字串的內容

4、應用場景：

統計網站訪問數量、當前線上人數、微博數、粉絲數等，incr命令(++操作)

5、實現方式：

String在redis內部儲存預設就是一個字串，被redisObject所引用，當遇到incr,decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。因為是二進位制安全的，所以可以用來儲存圖片。

二、list

1、雙向連結串列 有序 可重複

      也就是說對於一個具有上百萬個元素的lists來說，在頭部和尾部插入一個新元素，其時間複雜度是常數級別的，比如用LPUSH在10個元素的lists頭部插入新元素，和在上千萬元素的lists頭部插入新元素的速度應該是相同的。

2、應用：
2.1.我們可以利用lists來實現一個訊息佇列，而且可以確保先後順序，不必像MySQL那樣還需要通過ORDER BY來進行排序。
2.2.利用LRANGE還可以很方便的實現分頁的功能。

2.3.在部落格系統中，每個博文的評論也可以存入一個單獨的list中。

Redis list的實現為一個雙向連結串列，即可以支援反向查詢和遍歷，更方便操作，不過帶來了部分額外的記憶體開銷，Redis內部的很多實現，包括髮送緩衝佇列等也都是用的這個資料結構。

三、set

1、String 無序 不重複 集合

2、應用場景：

      QQ有一個社交功能叫做“好友標籤”，大家可以給你的好友貼標籤，比如“大美女”、“土豪”、“歐巴”等等，這時就可以使用redis的集合來實現，把每一個使用者的標籤都儲存在一個集合之中。

      Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要儲存一個列表資料，又不希望出現重複資料時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的。
3、實現方式：

     set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

四、sorted set

1、String 有序 不重複 集合

在sort的基礎上，使用double型別的score來確定順序

2、應用場景：

2.1當你需要一個有序的並且不重複的集合列表，那麼可以選擇sorted set資料結構；

3、實現方式：

五、Hash

1、string  field/value

2、應用場景：

適合用於儲存物件，例如儲存、讀取、修改使用者屬性（name，age，pwd等）

比如，我們要儲存一個使用者資訊物件資料，包含以下資訊：
使用者ID為查詢的key，儲存的value使用者物件包含姓名，年齡，生日等資訊，如果用普通的key/value結構來儲存，主要有以下2種儲存方式：
第一種方式將使用者ID作為查詢key,把其他資訊封裝成一個物件以序列化的方式儲存，這種方式的缺點是，增加了序列化/反序列化的開銷，並且在需要修改其中一項資訊時，需要把整個物件取回，並且修改操作需要對併發進行保護，引入CAS等複雜問題。
第二種方法是這個使用者資訊物件有多少成員就存成多少個key-value對兒，用使用者ID+對應屬性的名稱作為唯一標識來取得對應屬性的值，雖然省去了序列化開銷和併發問題，但是使用者ID為重複儲存，如果存在大量這樣的資料，記憶體浪費還是非常可觀的。
那麼Redis提供的Hash很好的解決了這個問題，Redis的Hash實際是內部儲存的Value為一個HashMap，並提供了直接存取這個Map成員的介面，
也就是說，Key仍然是使用者ID, value是一個Map，這個Map的key是成員的屬性名，value是屬性值，這樣對資料的修改和存取都可以直接通過其內部Map的Key(Redis裡稱內部Map的key為field), 也就是通過 key(使用者ID) + field(屬性標籤) 就可以操作對應屬性資料了，既不需要重複儲存資料，也不會帶來序列化和併發修改控制的問題。很好的解決了問題。

這裡同時需要注意，Redis提供了介面(hgetall)可以直接取到全部的屬性資料,但是如果內部Map的成員很多，那麼涉及到遍歷整個內部Map的操作，由於Redis單執行緒模型的緣故，這個遍歷操作可能會比較耗時，而另其它客戶端的請求完全不響應，這點需要格外注意。

3、實現方式

redis的Hash資料型別的value內部是一個HashMap，如果該Map的成員比較少，則會採用一維陣列的方式來緊湊儲存該Map，省去了大量指標的記憶體開銷，這個引數在redis.conf配置檔案中下面2項。

Hash-max-zipmap-entries 64
Hash-max-zipmap-value 512

• 1
• 2

Hash-max-zipmap-entries含義：是當value這個Map內部不超過64個成員時會採用線性緊湊格式儲存（預設是64），即value內部有64個以下的成員就是使用線性緊湊儲存，超過該值自動轉成真正的HashMap。 
Hash-max-zipmap-value含義：是當value這個Map內部的每個成員值長度不超過多少位元組就會採用線性緊湊儲存來節省空間。

以上兩個條件任意一個條件超過設定值都會轉成真正的HashMap，也就不會再節省記憶體了，這個值設定多少需要權衡，HashMap的優勢就是查詢和操作效率高。