Redis五種數(shù)據(jù)結構如下：

1.String 字符串類型

是redis中最基本的數(shù)據(jù)類型，一個key對應一個value。

String類型是二進制安全的，意思是 redis 的 string 可以包含任何數(shù)據(jù)。如數(shù)字，字符串，jpg圖片或者序列化的對象。

2.Hash (哈希)

是一個Mapmap，指值本身又是一種鍵值對結構，如 value={{field1,value1},......fieldN,valueN}}

3.鏈表 (List)

List 說白了就是鏈表(redis 使用雙端鏈表實現(xiàn)的 List)，是有序的，value可以重復，可以通過下標取出對應的value值，左右兩邊都能進行插入和刪除數(shù)據(jù)。

4.Set 集合

集合類型也是用來保存多個字符串的元素，但和列表不同的是集合中 1. 不允許有重復的元素，2.集合中的元素是無序的，不能通過索引下標獲取元素，3.支持集合間的操作，可以取多個集合取交集、并集、差集。

5.zset 有序集合

有序集合和集合有著必然的聯(lián)系，保留了集合不能有重復成員的特性，區(qū)別是，有序集合中的元素是可以排序的，它給每個元素設置一個分數(shù)，作為排序的依據(jù)。

應用場景

String應用場景

1. 單值緩存

Set Key Value

Get Key

2. 對象緩存

1.Set user:1 value (json格式數(shù)據(jù))

2.MSet user:1:name guajia use:1:balance 1888

MGet user1:name user:1:balance

3. 分布式鎖：

3.1 分布式運用場景一【下單減庫存】

如圖標紅的部分，如果是單體架構 我們一般是這樣來實現(xiàn)減庫存操作的 但是在高并發(fā)的互聯(lián)網(wǎng)公司這樣做，就會造成“超賣”的現(xiàn)象。所以就需要redis來實現(xiàn)分布式鎖

如上圖標記SETNX命令 它只會存入一個不存在的鍵值對，如果不會改變原來的key所存入的值，返回結果為0

SETNX product:10001 true //返回1代表獲取鎖成功 返回0代表獲取鎖失敗---》 執(zhí)行業(yè)務操作

如果setnx 命令返回0 直接扔給前端后端服務正忙 請稍后重試】 DEL product:10001 //執(zhí)行完業(yè)務用它來釋放鎖

SET product:10001 true ex 10 nx //防止程序意外終止而導致死鎖

3.2 分布式運用場景二

INCR 命令 每次執(zhí)行 所存儲的key的值 數(shù)量加1 (如果用數(shù)據(jù)庫的話 需要考慮并發(fā)和加鎖) 【注：redis是個單線程應用程序 這樣不會導致高并發(fā)的臟讀,主從的redis 在后面會使用分布式鎖，一般單體的redis并發(fā)量在9-10萬左右 】

3.3 分布式運用場景三 【 Web集群的session 共享 】

原理是把原有的tomcat存儲用戶信息轉為redis 把用戶的信息 序列化后 存入redis。

3.4 分布式運用場景四【 分布式系統(tǒng)全局序列號 】

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 命令 對已有值進行增量操作

有人可能會問，如果減少加購數(shù)量？騷年 你太年輕了 可以把增量的值調為-1 那每次就是減1

獲取購物車商品總數(shù) hlen cart:1001 [這邊把商品id去掉就行了 前提是你所有的加購設置key 和field的格式是一樣的 不然查出來的數(shù)量肯定不對] //它返回的是key下的所有field數(shù)量

涉及刪除商品，使用刪除的命令 hdel cart:1001 10088

獲取加購商品的總數(shù)量 使用hgetall cart:1001 //它返回的key下的所有鍵值，可以把所有的值加起來就是加購商品總數(shù)量

hash的優(yōu)點 缺點

hash的會分配槽位，集群中 會導致數(shù)據(jù)過于集中，沒辦法做分片。

List應用場景

仔細看命令前綴 有L 和R 分別代表左和右。

常用的數(shù)據(jù)結構

棧: LPUSH +LPOP = > 放進去的數(shù)據(jù)放在左邊 導致最后放進去的元素處于棧頂 最先的元素是處于棧底 使用LPOP 取值【或稱移除值】是先從最左側【棧頂】取值的 符合 先進后出的規(guī)則 【FILO】

隊列： 與上面相反 取值時是使用RPOP 是 移除值是從最右側開始的 所有最后進入的會被取出 符合 隊列的先進先出的規(guī)則【FIFO】

**BLOCKIng MQ(阻塞隊列) **: = LPUSH　＋BRPOP [這個就是一個消息隊列 ，消息隊列中有個發(fā)送者 和 接受者 ]

BRPOP 就是從key列表尾彈出一個元素，如果列表中沒有元素，就會一直處于阻塞等待多少秒，后面又會循環(huán)地執(zhí)行 直到取到元素為止

運用的場景一 【微博和公眾號的消息流】

如微博你關注了1000個大V 每個大V 一天放兩條數(shù)據(jù) ，有1億用戶 。那么數(shù)據(jù)量有多大。可能有幾百M的數(shù)據(jù)。 如果使用數(shù)據(jù)庫 查詢效率那就不是很高了

比如 你關注了小明和小紅。

小明發(fā)了一條消息： 使用 LPUSH msg:小明Id 消息Id 小紅發(fā)了一條消息： 使用 LPUSH msg:小紅Id 消息Id

查看最新的微博消息： 使用LRANGE msg:小紅Id 0 4 這個就是從左側取下標是0到4的消息 意味著是取小紅發(fā)的最新的5條消息的消息ID 進而從緩存里面取出對應的消息內容

SET應用場景

常見命令

運用的場景一 【微信抽獎】

1.參與抽獎： SADD key 用戶id ： 參與了用戶的id

2.查看參與抽獎的又會: SMEMBERS key

抽取n名中獎者

方式一：DMEMBER key [count]

方式二： SPOP key [count]

方式一和方式二的運用常見是 方式一 只有中獎單一 沒有多次抽獎和設置獎品等級。因為方式一 每次執(zhí)行不會把抽取的數(shù)據(jù)刪掉，后面執(zhí)行還可能會抽取到原來的用戶

[ SRANDMEMBER key [count] 返回集合中一個或多個隨機數(shù)]

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

總結

以上是生活随笔為你收集整理的formdata.append加多个值_redis的五种数据结构和应用场景：微博微信点赞+加购物车等...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。