1 緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性分析

1.1 Redis 中如何保證緩存和數(shù)據(jù)庫(kù)雙寫時(shí)的數(shù)據(jù)一致性？

????????無(wú)論先操作db還是cache，都會(huì)有各自的問(wèn)題，根本原因是cache和db的更新不是一個(gè)原子操作，因此總會(huì)有不一致的問(wèn)題。想要徹底解決這種問(wèn)題必須將cache和db的更新操作歸在一個(gè)事務(wù)之下（例如使用一些分布式事務(wù)，或者強(qiáng)一致性的分布式協(xié)議）。或者采用串行化，可以保證強(qiáng)一致性。

1.1.1 寫請(qǐng)求為什么更新數(shù)據(jù)庫(kù)后是刪除緩存而不是更新緩存？

????????注意看上面的圖片，當(dāng)有兩個(gè)寫請(qǐng)求的線程，線程一比線程二先執(zhí)行，反而是線程二先執(zhí)行完。這時(shí)候，緩存保存的是A的數(shù)據(jù)（老數(shù)據(jù)），數(shù)據(jù)庫(kù)保存的是B的數(shù)據(jù)（新數(shù)據(jù)），數(shù)據(jù)不一致了。

1.1.2 寫請(qǐng)求時(shí)，為什么更新數(shù)據(jù)庫(kù)，然后再刪除緩存？

????????如果采用寫請(qǐng)求，先刪除緩存，再更新數(shù)據(jù)庫(kù)就會(huì)出現(xiàn)如上圖的情況，線程B讀到的是老的數(shù)據(jù)，并且緩存中也保存的是老的數(shù)據(jù)。

1.1.3 寫請(qǐng)求時(shí)，先更新數(shù)據(jù)，后刪除緩存一定沒(méi)有問(wèn)題嗎？

????????可以看到一個(gè)讀請(qǐng)求和一個(gè)寫請(qǐng)求，讀請(qǐng)求可能會(huì)讀取到舊的數(shù)據(jù)，或者當(dāng)寫請(qǐng)求刪除緩存失敗，讀請(qǐng)求會(huì)一直讀取的是舊的緩存數(shù)據(jù)。只不過(guò)是這種情況，相對(duì)于其他的實(shí)現(xiàn)方式概率要低很多。

1.2 三種方案保證數(shù)據(jù)庫(kù)與緩存的一致性

1.2.1 緩存延時(shí)雙刪

????????第二次刪除緩存一般會(huì)采用延時(shí)的操作，主要是用來(lái)刪除讀請(qǐng)求產(chǎn)生的緩存數(shù)據(jù)

1.2.2 刪除緩存重試機(jī)制

????????延時(shí)雙刪和普通寫操作的刪除操作都有可能會(huì)操作失敗，導(dǎo)致數(shù)據(jù)不一致，刪除重試機(jī)制就是為了保證刪除可靠性。（刪除失敗的key放到消息隊(duì)列中）這種機(jī)制會(huì)造成大量的業(yè)務(wù)代碼入侵。

1.2.3 讀取biglog異步刪除緩存

????????通過(guò)binlog日志，將要?jiǎng)h除的key發(fā)送到消息隊(duì)列中。

1.3 如何使用 Redis 做異步隊(duì)列和延時(shí)隊(duì)列？

1.3.1 延時(shí)隊(duì)列

????????將需要延時(shí)執(zhí)行的任務(wù)放到 Redis 中的 Zset 類型中，Zset會(huì)根據(jù) score 自動(dòng)進(jìn)行數(shù)據(jù)排序（score使用時(shí)間戳），定義一個(gè)延時(shí)任務(wù)檢測(cè)器，檢測(cè)器使用 zrangebysocre 命令查詢 Redis 中符合執(zhí)行條件的任務(wù)執(zhí)行.

1.3.2 異步隊(duì)列

????????Redis的隊(duì)列l(wèi)ist是有序的且可以重復(fù)的，作為消息隊(duì)列使用時(shí)可使用rpush/lpush操作入隊(duì)，使用lpop/rpop操作出隊(duì)。當(dāng)發(fā)布消息是執(zhí)行l(wèi)push命令，將消息從列表左側(cè)加入隊(duì)列。消息接收方執(zhí)行rpop命令從列表右側(cè)彈出消息。

????????如果隊(duì)列空了，消費(fèi)者會(huì)陷入pop死循環(huán)，即使沒(méi)有數(shù)據(jù)也不會(huì)停止?？蛰喸儾坏南M(fèi)者的CPU資源還會(huì)影響Redis的性能。并且需要不停的調(diào)用rpop查看列表中是否有待處理的消息。每調(diào)用一次都會(huì)發(fā)起一次連接，勢(shì)必造成不必要的資源浪費(fèi)。

????????入隊(duì)的速度大于出隊(duì)的速度，消息隊(duì)列長(zhǎng)度會(huì)一直增大，時(shí)間長(zhǎng)了會(huì)占用大量的空間。

????????針對(duì)上面的 rpop 命令會(huì)一直阻塞隊(duì)列，Redis提供了一種更優(yōu)的 brpop命令，brpop可以設(shè)置一個(gè)超時(shí)時(shí)間，

1.4 Redis 中的過(guò)期策略

Redis 中的過(guò)期策略共有三種：

1. 定時(shí)刪除
2. 定期刪除
3. 惰性刪除

????????Redis 采用的過(guò)期策略是 定期+惰性 刪除。

1.4.1 定時(shí)刪除

????????在設(shè)置key的過(guò)期時(shí)間的同時(shí)為該key創(chuàng)建一個(gè)定時(shí)器，讓定時(shí)器在key的過(guò)期時(shí)間來(lái)臨時(shí)，對(duì)key進(jìn)行刪除

優(yōu)點(diǎn)： 保證內(nèi)存被盡快釋放

缺點(diǎn)： 過(guò)期的key太多，刪除這些key會(huì)占用很多的CPU時(shí)間。設(shè)置了過(guò)多的定時(shí)器，會(huì)對(duì)redis 的性能造成影響。

1.4.2 定期刪除

????????默認(rèn)一段時(shí)間就去隨機(jī)部分掃描redis中的設(shè)置了過(guò)期時(shí)間的key，檢查是否過(guò)期，過(guò)期的話就移除key。

1.4.2.1 為什么定期刪除只掃描部分設(shè)置了過(guò)期時(shí)間的key

????????因?yàn)閽呙枞康膋ey會(huì)非常多，很影響性能。

1.4.3 惰性刪除

????????惰性刪除就是等到有查詢key的請(qǐng)求過(guò)來(lái)的時(shí)候，我看看這個(gè)key有沒(méi)有過(guò)期，過(guò)期的話就刪除這個(gè)key。

缺點(diǎn)： 可能會(huì)造成內(nèi)存泄漏

1.5 Redis 中的內(nèi)存淘汰機(jī)制

????????設(shè)置方式： config set maxmemory-policy volatile-lru

• no-eviction: 禁止驅(qū)逐數(shù)據(jù)（當(dāng)內(nèi)存達(dá)到限制時(shí)，就報(bào)錯(cuò)）
• allkeys-lru： 從redis 中回收最近使用最少的鍵
• volatile-lru： 從設(shè)置了過(guò)期時(shí)間的鍵中，回收最近使用最少的鍵
• allkeys-random：隨機(jī)回收redis中的鍵
• volitile-random：從設(shè)置了過(guò)期時(shí)間的鍵中，隨機(jī)回收
• volitile-ttl：從設(shè)置了過(guò)期時(shí)間的鍵中，回收存活時(shí)間較少的鍵

????????關(guān)于volatile-lru：LRU 算法實(shí)現(xiàn)：1.通過(guò)雙向鏈表來(lái)實(shí)現(xiàn)，新數(shù)據(jù)插入到鏈表頭部；2.每當(dāng)緩存命中（即緩 存數(shù)據(jù)被訪問(wèn)），則將數(shù)據(jù)移到鏈表頭部；3.當(dāng)鏈表滿的時(shí)候，將鏈表尾部的數(shù)據(jù)丟棄。

????????指定redis 的淘汰策略

# maxmemory-policy noeviction

2 緩存更新機(jī)制

????????當(dāng)執(zhí)行寫操作后，需要保證從緩存讀取到的數(shù)據(jù)與數(shù)據(jù)庫(kù)中的數(shù)據(jù)是一致的，因此需要對(duì)緩存進(jìn)行更新。因?yàn)樯婕暗綌?shù)據(jù)庫(kù)和緩存兩步操作，難以保證更新的原子性。在設(shè)計(jì)更新策略時(shí)，我們需要考慮多個(gè)方面的問(wèn)題，對(duì)系統(tǒng)吞吐量的影響、并發(fā)安全性、更新失敗的影響。

????????更新緩存有兩種方式:

1. 刪除失效緩存: 讀取時(shí)會(huì)因?yàn)槲疵芯彺娑鴱臄?shù)據(jù)庫(kù)中讀取新的數(shù)據(jù)并更新到緩存中
2. 更新緩存: 直接將新的數(shù)據(jù)寫入緩存覆蓋過(guò)期數(shù)據(jù)

????????更新緩存和更新數(shù)據(jù)庫(kù)有兩種順序：

1. 先數(shù)據(jù)庫(kù)后緩存
2. 先緩存后數(shù)據(jù)庫(kù)

????????兩兩組合共有四種更新策略，現(xiàn)在我們逐一進(jìn)行分析。

2.1 更新策略分析

????????先做一個(gè)說(shuō)明，從理論上來(lái)說(shuō)，給緩存設(shè)置過(guò)期時(shí)間，是保證最終一致性的解決方案。這種方案下，我們可以對(duì)存入緩存的數(shù)據(jù)設(shè)置過(guò)期時(shí)間，所有的寫操作以數(shù)據(jù)庫(kù)為準(zhǔn)，對(duì)緩存操作只是盡最大努力即可。也就是說(shuō)如果數(shù)據(jù)庫(kù)寫成功，緩存更新失敗，那么只要到達(dá)過(guò)期時(shí)間，則后面的讀請(qǐng)求自然會(huì)從數(shù)據(jù)庫(kù)中讀取新值然后回填緩存。

2.1.1 先更新數(shù)據(jù)庫(kù)，再刪除緩存（推薦）

????????若數(shù)據(jù)庫(kù)更新成功，刪除緩存操作失敗，則此后讀到的都是緩存中過(guò)期的數(shù)據(jù)，造成不一致問(wèn)題。

????????假設(shè)這會(huì)有兩個(gè)請(qǐng)求，一個(gè)請(qǐng)求A做查詢操作，一個(gè)請(qǐng)求B做更新操作，那么會(huì)有如下情形產(chǎn)生：

（1）緩存剛好失效；

（2）請(qǐng)求A查詢數(shù)據(jù)庫(kù)，得一個(gè)舊值；

（3）請(qǐng)求B將新值寫入數(shù)據(jù)庫(kù)；

（4）請(qǐng)求B刪除緩存；

（5）請(qǐng)求A將查到的舊值寫入緩存；

????????假設(shè)，有人非要抬杠，有強(qiáng)迫癥，一定要解決怎么辦？

????????如何解決上述并發(fā)問(wèn)題？首先，給緩存設(shè)置有效時(shí)間是一種方案。其次，采用異步延時(shí)刪除策略，redis自己起一個(gè)線程，異步刪除保證讀請(qǐng)求完成以后，再進(jìn)行刪除操作。

2.1.2 先更新數(shù)據(jù)庫(kù)，再更新緩存（反對(duì)）

????????同刪除緩存策略一樣，若數(shù)據(jù)庫(kù)更新成功緩存更新失敗則會(huì)造成數(shù)據(jù)不一致問(wèn)題。反對(duì)此方案

原因一（線程安全角度）

????????同時(shí)有請(qǐng)求A和請(qǐng)求B進(jìn)行更新操作，那么會(huì)出現(xiàn)：

（1）線程A更新了數(shù)據(jù)庫(kù)

（2）線程B更新了數(shù)據(jù)庫(kù)

（3）線程B更新了緩存

（4）線程A更新了緩存

?????????這就出現(xiàn)請(qǐng)求A更新緩存應(yīng)該比請(qǐng)求B更新緩存早才對(duì)，但是因?yàn)榫W(wǎng)絡(luò)等原因，B卻比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù)，因此不考慮。

原因二（業(yè)務(wù)場(chǎng)景角度）

有如下兩點(diǎn)：

（1）如果你是一個(gè)寫數(shù)據(jù)庫(kù)場(chǎng)景比較多，而讀數(shù)據(jù)場(chǎng)景比較少的業(yè)務(wù)需求，采用這種方案就會(huì)導(dǎo)致，數(shù)據(jù)壓根還沒(méi)讀到，緩存就被頻繁的更新，浪費(fèi)性能。

（2）如果你寫入數(shù)據(jù)庫(kù)的值，并不是直接寫入緩存的，而是要經(jīng)過(guò)一系列復(fù)雜的計(jì)算再寫入緩存。那么，每次寫入數(shù)據(jù)庫(kù)后，都再次計(jì)算寫入緩存的值，無(wú)疑是浪費(fèi)性能的。顯然，刪除緩存更為適合。

????????接下來(lái)討論的就是爭(zhēng)議最大的，先刪緩存，再更新數(shù)據(jù)庫(kù)。還是先更新數(shù)據(jù)庫(kù)，再刪緩存的問(wèn)題。

2.1.3 先刪除緩存，再更新數(shù)據(jù)庫(kù)

????????該方案會(huì)導(dǎo)致不一致的原因是。同時(shí)有一個(gè)請(qǐng)求A進(jìn)行操作，另一個(gè)請(qǐng)求B進(jìn)行查詢操作。那么會(huì)出現(xiàn)如下情形:

（1）請(qǐng)求A進(jìn)行寫操作，刪除緩存；

（2）請(qǐng)求B查詢發(fā)現(xiàn)緩存不存在；

（3）請(qǐng)求B去數(shù)據(jù)庫(kù)查詢得到舊值；

（4）請(qǐng)求B將舊值寫入緩存；

（5）請(qǐng)求A將新值寫入數(shù)據(jù)庫(kù)；

????????上述情況就會(huì)導(dǎo)致不一致的情形出現(xiàn)。而且，如果不采用給緩存設(shè)置過(guò)期時(shí)間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。

????????那么，如何解決呢？

????????采用延時(shí)雙刪策略：

（1）先淘汰刪除緩存；

（2）再寫數(shù)據(jù)庫(kù)（這兩步和原來(lái)一樣）；

（3）休眠1秒，再次淘汰緩存；

????????這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。那么，這個(gè)1秒怎么確定的，具體該休眠多久呢？這確實(shí)需要根據(jù)實(shí)際情況而定：

????????如果你用了MySQL的讀寫分離架構(gòu)怎么辦？還是使用延時(shí)雙刪策略。

????????采用這種同步淘汰策略，吞吐量降低怎么辦？ok，那就將第二次刪除作為異步的。自己起一個(gè)線程，異步刪除。

????????第二次刪除，如果刪除失敗怎么辦？這是個(gè)非常好的問(wèn)題，因?yàn)榈诙蝿h除失敗，就會(huì)出現(xiàn)如下情形。還是有兩個(gè)請(qǐng)求，一個(gè)請(qǐng)求A進(jìn)行更新操作，另一個(gè)請(qǐng)求B進(jìn)行查詢操作，為了方便，假設(shè)是單庫(kù)：

（1）請(qǐng)求A進(jìn)行寫操作，刪除緩存；

（2）請(qǐng)求B查詢發(fā)現(xiàn)緩存不存在；

（3）請(qǐng)求B去數(shù)據(jù)庫(kù)查詢得到舊值；

（4）請(qǐng)求B將舊值寫入緩存；

（5）請(qǐng)求A將新值寫入數(shù)據(jù)庫(kù)；

（6）請(qǐng)求A試圖去刪除請(qǐng)求B寫入對(duì)緩存值，結(jié)果失敗了。

????????ok,這也就是說(shuō)。如果第二次刪除緩存失敗，會(huì)再次出現(xiàn)緩存和數(shù)據(jù)庫(kù)不一致的問(wèn)題。

如何解決呢？

2.1.4 先更新緩存，再更新數(shù)據(jù)庫(kù)（反對(duì)）

????????若緩存更新成功數(shù)據(jù)庫(kù)更新失敗， 則此后讀到的都是未持久化的數(shù)據(jù)。因?yàn)榫彺嬷械臄?shù)據(jù)是易失的，這種狀態(tài)非常危險(xiǎn)。

2.2 緩存雪崩/擊穿/穿透

????????正常情況下的流程是這樣的，先查緩存，緩存無(wú)就查數(shù)據(jù)庫(kù)。

2.2.1 緩存雪崩

????????緩存雪崩是指緩存中的數(shù)據(jù)大批量的過(guò)期 ，而查詢量巨大，造成數(shù)據(jù)庫(kù)壓力過(guò)大而崩潰。

解決方法：

1. 緩存的過(guò)期時(shí)間隨機(jī)設(shè)置，防止大量數(shù)據(jù)同時(shí)過(guò)期。
2. 盡量保證redis集群的高可用性，當(dāng)發(fā)現(xiàn)機(jī)器墜機(jī)時(shí)盡快補(bǔ)上。
3. 選擇合適的緩存淘汰策略。

2.2.2 緩存擊穿

????????緩存擊穿是指緩存中沒(méi)有數(shù)據(jù)，而數(shù)據(jù)庫(kù)中有數(shù)據(jù)，一般是緩存中的數(shù)據(jù)過(guò)期了，然后很多用戶并發(fā)查詢?cè)摂?shù)據(jù)，同時(shí)在緩存中讀取該數(shù)據(jù)沒(méi)讀取到，就同時(shí)去數(shù)據(jù)庫(kù)中查，造成數(shù)據(jù)庫(kù)壓力過(guò)大。緩存擊穿強(qiáng)調(diào)的是一個(gè)數(shù)據(jù)過(guò)期，同時(shí)并發(fā)地去數(shù)據(jù)庫(kù)訪問(wèn)該數(shù)據(jù)；而緩存雪崩是強(qiáng)調(diào)大量的數(shù)據(jù)過(guò)期。

解決方法：

1. 設(shè)置熱點(diǎn)數(shù)據(jù)永不過(guò)期。
2. 加互斥鎖。邏輯如下：從緩存中獲取當(dāng)前數(shù)據(jù)，如果緩存中沒(méi)有，則嘗試去獲取鎖，如果獲取成功則查詢數(shù)據(jù)庫(kù)，然后寫進(jìn)緩存，然后釋放鎖。

2.2.3 緩存穿透

????????緩存穿透是指緩存中沒(méi)有該數(shù)據(jù)，數(shù)據(jù)庫(kù)中也沒(méi)有該數(shù)據(jù)。而用戶不斷地發(fā)請(qǐng)求，比如不斷發(fā)出一些id=-1或者是根本就很不合理的數(shù)據(jù)來(lái)發(fā)生請(qǐng)求。這種一般是別人想攻擊你。攻擊會(huì)導(dǎo)致數(shù)據(jù)庫(kù)壓力過(guò)大。

? ????????對(duì)于這種情況很好解決，我們可以在redis緩存一個(gè)空字符串或者特殊字符串，比如&&，下次我們?nèi)edis中查詢的時(shí)候，當(dāng)取到的值是空或者&&，我們就知道這個(gè)值在數(shù)據(jù)庫(kù)中是沒(méi)有的，就不會(huì)再去數(shù)據(jù)庫(kù)中查詢，ps：這里緩存不存在key的時(shí)候一定要設(shè)置過(guò)期時(shí)間，不然當(dāng)數(shù)據(jù)庫(kù)已經(jīng)新增了這一條記錄的時(shí)候，這樣會(huì)導(dǎo)致緩存和數(shù)據(jù)庫(kù)不一致的情況。

????????上面這個(gè)只是重復(fù)查詢同一個(gè)不存在的值的情況，如果每次查詢的不存在的值是不一樣的呢？那怎么辦，難道自己手動(dòng)緩存許多特殊字符串嗎？別人想攻擊你，即使你每次緩存很多特殊字符串也沒(méi)用，太有概率性了，這時(shí)候數(shù)據(jù)庫(kù)的壓力是相當(dāng)大，怎么辦呢，布隆過(guò)濾器就登場(chǎng)了。

????????布隆過(guò)濾器使用場(chǎng)景：

①、原本有10億個(gè)數(shù)，現(xiàn)在又來(lái)了10萬(wàn)個(gè)數(shù)，要快速準(zhǔn)確判斷這10萬(wàn)個(gè)數(shù)是否在10億個(gè)數(shù)庫(kù)中？

• 辦法一：將10億個(gè)數(shù)存入數(shù)據(jù)庫(kù)，再數(shù)據(jù)庫(kù)查詢，查出值為null，代表不存在，準(zhǔn)確性有了，但是速度會(huì)比較慢。
• 辦法二：將10億數(shù)放入內(nèi)存中，比如Redis中，這里我們算一下占用內(nèi)存大?。?0億*8字節(jié)=8GB，通過(guò)內(nèi)存查詢，準(zhǔn)確性和速度都有了，但是大約8GB的內(nèi)存空間，挺浪費(fèi)內(nèi)存空間的。

????????那么對(duì)于類似這種，大數(shù)據(jù)量集合，如何準(zhǔn)確快速的判斷某個(gè)數(shù)據(jù)是否在大數(shù)據(jù)量集合中，并且不占用內(nèi)存，布隆過(guò)濾器應(yīng)運(yùn)而生了。

布隆過(guò)濾器：使用位圖實(shí)現(xiàn)，是由一串很長(zhǎng)的二進(jìn)制向量組成，數(shù)組中只存在0.1

????????當(dāng)要向布隆過(guò)濾器中添加一個(gè)元素key時(shí)，我們通過(guò)多個(gè)hash函數(shù)，算出一個(gè)值，然后將這個(gè)值所在的方格置為1。 如下圖：

如何查詢是否存在呢？

????????我們只需要將這個(gè)新的數(shù)據(jù)通過(guò)上面自定義的幾個(gè)哈希函數(shù)，分別算出各個(gè)值，然后看其對(duì)應(yīng)的地方是否都是1，如果存在一個(gè)不是1的情況，那么我們可以說(shuō)，該新數(shù)據(jù)一定不存在于這個(gè)布隆過(guò)濾器中。

????????反過(guò)來(lái)說(shuō)，如果通過(guò)哈希函數(shù)算出來(lái)的值，對(duì)應(yīng)的地方都是1，那么我們能夠肯定的得出：這個(gè)數(shù)據(jù)一定存在于這個(gè)布隆過(guò)濾器中嗎？

????????答案是否定的，因?yàn)槎鄠€(gè)不同的數(shù)據(jù)通過(guò)hash函數(shù)算出來(lái)的結(jié)果是會(huì)有重復(fù)的，所以會(huì)存在某個(gè)位置是別的數(shù)據(jù)通過(guò)hash函數(shù)置為的1。比如這個(gè)d，通過(guò)三次計(jì)算發(fā)現(xiàn)得到的結(jié)果也都是1，那么我們能說(shuō)d在布隆過(guò)濾器中是存在的嗎，顯然是不行的，我們仔細(xì)看d得到的三個(gè)1其實(shí)是f1(a)，f1(b)，f2?存進(jìn)去的，并不是d自己存進(jìn)去的，這個(gè)還是哈希碰撞導(dǎo)致的。

????????結(jié)論：布隆過(guò)濾器可以判斷某個(gè)數(shù)據(jù)一定不存在，但是無(wú)法判斷一定存在。

參考鏈接

Redis的緩存更新策略和緩存問(wèn)題_redis更新緩存數(shù)據(jù)_〖雪月清〗的博客-CSDN博客

Redis-基本概念_redis定義_SeaDhdhdhdhdh的博客-CSDN博客

一文搞懂 Redis 架構(gòu)演化之路?

Redis設(shè)計(jì)與實(shí)現(xiàn)

redis架構(gòu)_劍八-的博客-CSDN博客

Redis高可用方案—主從（masterslave）架構(gòu)

Redis高可用架構(gòu)—哨兵（sentinel）機(jī)制詳細(xì)介紹

Redis高可用架構(gòu)—Redis集群（Redis Cluster）詳細(xì)介紹

Redis基本概念知識(shí)_redis 基本概念_Gatsby_codeLife的博客-CSDN博客

03 Redis 網(wǎng)絡(luò)IO模型簡(jiǎn)介_(kāi)redis的io模型_天秤座的架構(gòu)師的博客-CSDN博客

Redis 詳解_王叮咚的博客-CSDN博客文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-687012.html

到了這里，關(guān)于【云原生進(jìn)階之PaaS中間件】第一章Redis-2.4緩存更新機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！