redis五種數據結構如下：
1.String 字符串類型
是redis中最基本的數據類型，一個key對應一個value。
String類型是二進制安全的，意思是 redis 的 string 可以包含任何數據。如數字，字符串，jpg圖片或者序列化的對象。
2.Hash （哈希）
是一個Mapmap，指值本身又是一種鍵值對結構，如 value={{field1,value1},......fieldN,valueN}}
3.鏈表 (List)
List 說白了就是鏈表（redis 使用雙端鏈表實現的 List），是有序的，value可以重復，可以通過下標取出對應的value值，左右兩邊都能進行插入和刪除數據。
4.Set 集合
集合類型也是用來保存多個字符串的元素，但和列表不同的是集合中 1. 不允許有重復的元素，2.集合中的元素是無序的，不能通過索引下標獲取元素，3.支持集合間的操作，可以取多個集合取交集、并集、差集。
5.zset 有序集合
有序集合和集合有著必然的聯系，保留了集合不能有重復成員的特性，區別是，有序集合中的元素是可以排序的，它給每個元素設置一個分數，作為排序的依據。
應用場景
String應用場景
1. 單值緩存
Set Key Value
Get Key
2. 對象緩存
1.Set user:1 value (json格式數據)
2.MSet user:1:name guajia use:1:balance 1888
MGet user1:name user:1:balance
3. 分布式鎖：
3.1 分布式運用場景一【下單減庫存】
如圖標紅的部分，如果是單體架構 我們一般是這樣來實現減庫存操作的 但是在高并發的互聯網公司這樣做，就會造成“超賣”的現象。所以就需要redis來實現分布式鎖
如上圖標記SETNX命令 它只會存入一個不存在的鍵值對，如果不會改變原來的key所存入的值，返回結果為0
SETNX product:10001 true //返回1代表獲取鎖成功 返回0代表獲取鎖失敗---》 執行業務操作
如果setnx 命令返回0 直接扔給前端后端服務正忙 請稍后重試】 DEL product:10001 //執行完業務用它來釋放鎖
SET product:10001 true ex 10 nx //防止程序意外終止而導致死鎖
3.2 分布式運用場景二
INCR 命令 每次執行 所存儲的key的值 數量加1 (如果用數據庫的話 需要考慮并發和加鎖) 【注：redis是個單線程應用程序 這樣不會導致高并發的臟讀,主從的redis 在后面會使用分布式鎖，一般單體的redis并發量在9-10萬左右 】
3.3 分布式運用場景三 【 Web集群的session 共享 】
原理是把原有的Tomcat存儲用戶信息轉為redis 把用戶的信息 序列化后 存入redis。
3.4 分布式運用場景四【 分布式系統全局序列號 】
INCRBY orderId 1000 // redis 批量生成序列號提升性能
如項目使用 分庫分表 ，就可以使用這個 ，目的是讓主鍵ID 在都是唯一的 ，這個在實際場景非常重要。
使用INCRBY orderId 1000 （這個命令是一次生成1000個訂單id 供下次生成訂單使用）
Hash應用場景
大家仔細看 Hset key field value 比string多出來了一個field
Hash應用場景一 【電商購物車】
如圖先示剛加入購物車的商品使用 hset cart:1001 10088 1,啥意思 cart代表的購物車 當然這個key 你可以隨意定 但是意義要讓所有人清楚，:1001 這里代表的是用戶id，后面的10088 代表的是商品id。
第二步 點擊 購物車的增加商品按鈕 可以使用hincrby 命令 對已有值進行增量操作
有人可能會問，如果減少加購數量？騷年 你太年輕了 可以把增量的值調為-1 那每次就是減1
獲取購物車商品總數 hlen cart:1001 [這邊把商品id去掉就行了 前提是你所有的加購設置key 和field的格式是一樣的 不然查出來的數量肯定不對] //它返回的是key下的所有field數量
涉及刪除商品，使用刪除的命令 hdel cart:1001 10088
獲取加購商品的總數量 使用hgetall cart:1001 //它返回的key下的所有鍵值，可以把所有的值加起來就是加購商品總數量
hash的優點 缺點
hash的會分配槽位，集群中 會導致數據過于集中，沒辦法做分片。
List應用場景
仔細看命令前綴 有L 和R 分別代表左和右。
常用的數據結構
棧: LPUSH +LPOP = > 放進去的數據放在左邊 導致最后放進去的元素處于棧頂 最先的元素是處于棧底 使用LPOP 取值【或稱移除值】是先從最左側【棧頂】取值的 符合 先進后出的規則 【FILO】
隊列： 與上面相反 取值時是使用RPOP 是 移除值是從最右側開始的 所有最后進入的會被取出 符合 隊列的先進先出的規則【FIFO】
**BLOCKIng MQ(阻塞隊列) **: = LPUSH ＋BRPOP [這個就是一個消息隊列 ，消息隊列中有個發送者 和 接受者 ]
BRPOP 就是從key列表尾彈出一個元素，如果列表中沒有元素，就會一直處于阻塞等待多少秒，后面又會循環地執行 直到取到元素為止
運用的場景一 【微博和公眾號的消息流】
如微博你關注了1000個大V 每個大V 一天放兩條數據 ，有1億用戶 。那么數據量有多大?？赡苡袔装費的數據。 如果使用數據庫 查詢效率那就不是很高了
比如 你關注了小明和小紅。
小明發了一條消息： 使用 LPUSH msg:小明Id 消息Id 小紅發了一條消息： 使用 LPUSH msg:小紅Id 消息Id
查看最新的微博消息： 使用LRANGE msg:小紅Id 0 4 這個就是從左側取下標是0到4的消息 意味著是取小紅發的最新的5條消息的消息ID 進而從緩存里面取出對應的消息內容
SET應用場景
常見命令
運用的場景一 【微信抽獎】
1.參與抽獎： SADD key 用戶id ： 參與了用戶的id
2.查看參與抽獎的又會: SMEMBERS key
- 抽取n名中獎者
方式一：DMEMBER key [count]
方式二： SPOP key [count]
方式一和方式二的運用常見是 方式一 只有中獎單一 沒有多次抽獎和設置獎品等級。因為方式一 每次執行不會把抽取的數據刪掉，后面執行還可能會抽取到原來的用戶
[ SRANDMEMBER key [count] 返回集合中一個或多個隨機數]
ps: like:{消息ID} 就是 key {用戶ID} 是 member
運用的場景三【微信微博關注模型】
SDIFF set1 set2 set3 是以 set1為基準 秋 與set2和set3的并集 的差集
[得到a是set2和set3的并集中所沒有的】
關注模型：
1.你關注的人
set guanzhu:我的id {張三、李四、王五、小明、程咬金}
2.小明關注的人
set guanzhu:小明的id {張三、趙六、尼古拉斯}
3.程咬金關注的人
set guanzhu:程咬金的id {小明、李四}
4.我和小明的共同關注：
SINTER guanzhu:我的id guanzhu:小明的id
得到就是 張三
5.我關注的人也在關注他 【我關注的某人 否也請關注小明】
SISMEMBER guanzhu:程咬金的id 小明的ID
SISMEMBER guanzhu:張三的id 小明的ID
SISMEMBER //判斷 member 元素是否是集合 key 的成員
6.我可能認識的人
SDIFF guanzhu:小明的id 我的ID
