如何解決Redis高并發(fā)競(jìng)爭(zhēng)key場(chǎng)景難點(diǎn)?
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
本篇就接著來談Redis在高并發(fā)的場(chǎng)景,如何來解決并發(fā)競(jìng)爭(zhēng)Key的解決方案。 01 — 并發(fā)競(jìng)爭(zhēng)的由來 1.Redis高并發(fā)的問題 Redis緩存的高性能有目共睹,應(yīng)用的場(chǎng)景也是非常廣泛,但是在高并發(fā)的場(chǎng)景下,也會(huì)出現(xiàn)問題:緩存擊穿、緩存雪崩、緩存和數(shù)據(jù)一致性,以及今天要談到的緩存并發(fā)競(jìng)爭(zhēng)。 這里的并發(fā)指的是多個(gè)redis的client同時(shí)set key引起的并發(fā)問題。 2.出現(xiàn)并發(fā)設(shè)置Key的原因 Redis是一種單線程機(jī)制的nosql數(shù)據(jù)庫,基于key-value,數(shù)據(jù)可持久化落盤。由于單線程所以Redis本身并沒有鎖的概念,多個(gè)客戶端連接并不存在競(jìng)爭(zhēng)關(guān)系,但是利用jedis等客戶端對(duì)Redis進(jìn)行并發(fā)訪問時(shí)會(huì)出現(xiàn)問題。 比如:同時(shí)有多個(gè)子系統(tǒng)去set一個(gè)key。這個(gè)時(shí)候要注意什么呢? 3.舉一個(gè)例子 多客戶端同時(shí)并發(fā)寫一個(gè)key,一個(gè)key的值是1,本來按順序修改為2,3,4,最后是4,但是順序變成了4,3,2,最后變成了2。
如何解決redis的并發(fā)競(jìng)爭(zhēng)key問題呢?下面給到2個(gè)Redis并發(fā)競(jìng)爭(zhēng)的解決方案。 02 — 第一種方案:分布式鎖+時(shí)間戳1.整體技術(shù)方案 這種情況,主要是準(zhǔn)備一個(gè)分布式鎖,大家去搶鎖,搶到鎖就做set操作。 加鎖的目的實(shí)際上就是把并行讀寫改成串行讀寫的方式,從而來避免資源競(jìng)爭(zhēng)。 2.Redis分布式鎖的實(shí)現(xiàn) 主要用到的redis函數(shù)是setnx() 用SETNX實(shí)現(xiàn)分布式鎖 利用SETNX非常簡(jiǎn)單地實(shí)現(xiàn)分布式鎖。例如:某客戶端要獲得一個(gè)名字mikechen的鎖,客戶端使用下面的命令進(jìn)行獲?。?/span> SETNX lock.mikechen<current Unix time + lock timeout + 1>
2.時(shí)間戳 由于上面舉的例子,要求key的操作需要順序執(zhí)行,所以需要保存一個(gè)時(shí)間戳判斷set順序。
假設(shè)系統(tǒng)B先搶到鎖,將key1設(shè)置為{ValueB 7:05}。接下來系統(tǒng)A搶到鎖,發(fā)現(xiàn)自己的key1的時(shí)間戳早于緩存中的時(shí)間戳(7:00<7:05),那就不做set操作了。 3.什么是分布式鎖 因?yàn)閭鹘y(tǒng)的加鎖的做法(如java的synchronized和Lock)這里沒用,只適合單點(diǎn)。因?yàn)檫@是分布式環(huán)境,需要的是分布式鎖。 當(dāng)然,分布式鎖可以基于很多種方式實(shí)現(xiàn),比如zookeeper、redis等,不管哪種方式實(shí)現(xiàn),基本原理是不變的:用一個(gè)狀態(tài)值表示鎖,對(duì)鎖的占用和釋放通過狀態(tài)值來標(biāo)識(shí)。 關(guān)于分布式鎖可以查看:分布式鎖的實(shí)現(xiàn)原理與應(yīng)用場(chǎng)景詳解 03 — 第二種方案:利用消息隊(duì)列在并發(fā)量過大的情況下,可以通過消息中間件進(jìn)行處理,把并行讀寫進(jìn)行串行化。 把Redis.set操作放在隊(duì)列中使其串行化,必須的一個(gè)一個(gè)執(zhí)行。 這種方式在一些高并發(fā)的場(chǎng)景中算是一種通用的解決方案。 閱讀原文:原文鏈接 該文章在 2025/7/1 23:52:44 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |