您好,登錄后才能下訂單哦!
小編給大家分享一下redis分布式如何實(shí)現(xiàn),希望大家閱讀完這篇文章后大所收獲,下面讓我們一起去探討吧!
在項(xiàng)目中使用 Redis,主要考慮兩個(gè)角度:性能和并發(fā)。如果只是為了分布式鎖這些其他功能,還有其他中間件 Zookpeer 等代替,并非一定要使用 Redis。
如下圖所示,我們?cè)谂龅?span>需要執(zhí)行耗時(shí)特別久,且結(jié)果不頻繁變動(dòng)的 SQL,就特別適合將運(yùn)行結(jié)果放入緩存。這樣,后面的請(qǐng)求就去緩存中讀取,使得請(qǐng)求能夠迅速響應(yīng)。
特別是在秒殺系統(tǒng),在同一時(shí)間,幾乎所有人都在點(diǎn),都在下單。。。執(zhí)行的是同一操作———向數(shù)據(jù)庫查數(shù)據(jù)。
根據(jù)交互效果的不同,響應(yīng)時(shí)間沒有固定標(biāo)準(zhǔn)。在理想狀態(tài)下,我們的頁面跳轉(zhuǎn)需要在瞬間解決,對(duì)于頁內(nèi)操作則需要在剎那間解決。
如下圖所示,在大并發(fā)的情況下,所有的請(qǐng)求直接訪問數(shù)據(jù)庫,數(shù)據(jù)庫會(huì)出現(xiàn)連接異常。這個(gè)時(shí)候,就需要使用 Redis 做一個(gè)緩沖操作,讓請(qǐng)求先訪問到 Redis,而不是直接訪問數(shù)據(jù)庫。
這個(gè)問題是對(duì) Redis 內(nèi)部機(jī)制的一個(gè)考察。很多人都不知道 Redis 是單線程工作模型。
仔細(xì)說一說 I/O 多路復(fù)用機(jī)制,打一個(gè)比方:小名在 A 城開了一家快餐店店,負(fù)責(zé)同城快餐服務(wù)。小明因?yàn)橘Y金限制,雇傭了一批配送員,然后小曲發(fā)現(xiàn)資金不夠了,只夠買一輛車送快遞。
客戶每下一份訂單,小明就讓一個(gè)配送員盯著,然后讓人開車去送。慢慢的小曲就發(fā)現(xiàn)了這種經(jīng)營(yíng)方式存在下述問題:
時(shí)間都花在了搶車上了,大部分配送員都處在閑置狀態(tài),搶到車才能去送。
小明只雇傭一個(gè)配送員。當(dāng)客戶下單,小明按送達(dá)地點(diǎn)標(biāo)注好,依次放在一個(gè)地方。最后,讓配送員依次開著車去送,送好了就回來拿下一個(gè)。上述兩種經(jīng)營(yíng)方式對(duì)比,很明顯第二種效率更高。
下面類比到真實(shí)的 Redis 線程模型,如圖所示:
Redis-client 在操作的時(shí)候,會(huì)產(chǎn)生具有不同事件類型的 Socket。在服務(wù)端,有一段 I/O 多路復(fù)用程序,將其置入隊(duì)列之中。然后,文件事件分派器,依次去隊(duì)列中取,轉(zhuǎn)發(fā)到不同的事件處理器中。
一個(gè)合格的程序員,這五種類型都會(huì)用到。
最常規(guī)的 set/get 操作,Value 可以是 String 也可以是數(shù)字。一般做一些復(fù)雜的計(jì)數(shù)功能的緩存。
這里 Value 存放的是結(jié)構(gòu)化的對(duì)象,比較方便的就是操作其中的某個(gè)字段。我在做單點(diǎn)登錄的時(shí)候,就是用這種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)用戶信息,以 CookieId 作為 Key,設(shè)置 30 分鐘為緩存過期時(shí)間,能很好的模擬出類似 Session 的效果。
使用 List 的數(shù)據(jù)結(jié)構(gòu),可以做簡(jiǎn)單的消息隊(duì)列的功能。另外,可以利用 lrange 命令,做基于 Redis 的分頁功能,性能極佳,用戶體驗(yàn)好。
因?yàn)?Set 堆放的是一堆不重復(fù)值的集合。所以可以做全局去重的功能。我們的系統(tǒng)一般都是集群部署,使用 JVM 自帶的 Set 比較麻煩。另外,就是利用交集、并集、差集等操作,可以計(jì)算共同喜好,全部的喜好,自己獨(dú)有的喜好等功能。
Sorted Set 多了一個(gè)權(quán)重參數(shù) Score,集合中的元素能夠按 Score 進(jìn)行排列??梢宰?span>排行榜應(yīng)用,取 TOP N 操作。Sorted Set 可以用來做延時(shí)任務(wù)。
Redis 是否用到家,從這就能看出來。比如你 Redis 只能存 5G 數(shù)據(jù),可是你寫了 10G,那會(huì)刪 5G 的數(shù)據(jù)。怎么刪的,這個(gè)問題思考過么?
正解:Redis 采用的是定期刪除+惰性刪除策略。
定時(shí)刪除,用一個(gè)定時(shí)器來負(fù)責(zé)監(jiān)視 Key,過期則自動(dòng)刪除。雖然內(nèi)存及時(shí)釋放,但是十分消耗 CPU 資源。在大并發(fā)請(qǐng)求下,CPU 要將時(shí)間應(yīng)用在處理請(qǐng)求,而不是刪除 Key,因此沒有采用這一策略。
定期刪除,Redis 默認(rèn)每個(gè) 100ms 檢查,有過期 Key 則刪除。需要說明的是,Redis 不是每個(gè) 100ms 將所有的 Key 檢查一次,而是隨機(jī)抽取進(jìn)行檢查。如果只采用定期刪除策略,會(huì)導(dǎo)致很多 Key 到時(shí)間沒有刪除。于是,惰性刪除派上用場(chǎng)。
不是的,如果定期刪除沒刪除掉 Key。并且你也沒及時(shí)去請(qǐng)求 Key,也就是說惰性刪除也沒生效。這樣,Redis 的內(nèi)存會(huì)越來越高。那么就應(yīng)該采用內(nèi)存淘汰機(jī)制。
在 redis.conf 中有一行配置:
# maxmemory-policy volatile-lru
一致性問題還可以再分為最終一致性和強(qiáng)一致性。數(shù)據(jù)庫和緩存雙寫,就必然會(huì)存在不一致的問題。前提是如果對(duì)數(shù)據(jù)有強(qiáng)一致性要求,不能放緩存。我們所做的一切,只能保證最終一致性。
另外,我們所做的方案從根本上來說,只能降低不一致發(fā)生的概率。因此,有強(qiáng)一致性要求的數(shù)據(jù),不能放緩存。首先,采取正確更新策略,先更新數(shù)據(jù)庫,再刪緩存。其次,因?yàn)?span>可能存在刪除緩存失敗的問題,提供一個(gè)補(bǔ)償措施即可,例如利用消息隊(duì)列。
這兩個(gè)問題,一般中小型傳統(tǒng)軟件企業(yè)很難碰到。如果有大并發(fā)的項(xiàng)目,流量有幾百萬左右,這兩個(gè)問題一定要深刻考慮。緩存穿透,即黑客故意去請(qǐng)求緩存中不存在的數(shù)據(jù),導(dǎo)致所有的請(qǐng)求都懟到數(shù)據(jù)庫上,從而數(shù)據(jù)庫連接異常。
緩存雪崩,即緩存同一時(shí)間大面積的失效,這個(gè)時(shí)候又來了一波請(qǐng)求,結(jié)果請(qǐng)求都懟到數(shù)據(jù)庫上,從而導(dǎo)致數(shù)據(jù)庫連接異常。
這個(gè)問題大致就是,同時(shí)有多個(gè)子系統(tǒng)去 Set 一個(gè) Key。這個(gè)時(shí)候要注意什么呢?大家基本都是推薦用 Redis 事務(wù)機(jī)制。
但是并不推薦使用 Redis 的事務(wù)機(jī)制。因?yàn)槲覀兊纳a(chǎn)環(huán)境,基本都是 Redis 集群環(huán)境,做了數(shù)據(jù)分片操作。你一個(gè)事務(wù)中有涉及到多個(gè) Key 操作的時(shí)候,這多個(gè) Key 不一定都存儲(chǔ)在同一個(gè) redis-server 上。因此,Redis 的事務(wù)機(jī)制,十分雞肋。
如果對(duì)這個(gè) Key 操作,不要求順序
這種情況下,準(zhǔn)備一個(gè)分布式鎖,大家去搶鎖,搶到鎖就做 set 操作即可,比較簡(jiǎn)單。
如果對(duì)這個(gè) Key 操作,要求順序
假設(shè)有一個(gè) key1,系統(tǒng) A 需要將 key1 設(shè)置為 valueA,系統(tǒng) B 需要將 key1 設(shè)置為 valueB,系統(tǒng) C 需要將 key1 設(shè)置為 valueC。
期望按照 key1 的 value 值按照 valueA > valueB > valueC 的順序變化。這種時(shí)候我們?cè)?span>數(shù)據(jù)寫入數(shù)據(jù)庫的時(shí)候,需要保存一個(gè)時(shí)間戳。
假設(shè)時(shí)間戳如下:
系統(tǒng) A key 1 {valueA 3:00}
系統(tǒng) B key 1 {valueB 3:05}
系統(tǒng) C key 1 {valueC 3:10}
那么,假設(shè)系統(tǒng) B 先搶到鎖,將 key1 設(shè)置為{valueB 3:05}。接下來系統(tǒng) A 搶到鎖,發(fā)現(xiàn)自己的 valueA 的時(shí)間戳早于緩存中的時(shí)間戳,那就不做 set 操作了,以此類推。其他方法,比如利用隊(duì)列,將 set 方法變成串行訪問也可以。
看完了這篇文章,相信你對(duì)redis分布式如何實(shí)現(xiàn)有了一定的了解,想了解更多相關(guān)知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道,感謝各位的閱讀!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。