本文小編為大家詳細(xì)介紹“java web實(shí)例分析”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“java web實(shí)例分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來(lái)學(xué)習(xí)新知識(shí)吧。

創(chuàng)新互聯(lián)專注于樂清企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站開發(fā),商城系統(tǒng)網(wǎng)站開發(fā)。樂清網(wǎng)站建設(shè)公司,為樂清等地區(qū)提供建站服務(wù)。全流程按需策劃設(shè)計(jì)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

正文

在實(shí)際的工作項(xiàng)目中， 緩存成為高并發(fā)、高性能架構(gòu)的關(guān)鍵組件 ，那么redis為什么可以作為緩存使用呢？首先可以作為緩存的兩個(gè)主要特征：

• 在分層系統(tǒng)中處于內(nèi)存/CPU具有訪問(wèn)性能良好，

• 緩存數(shù)據(jù)飽和，有良好的數(shù)據(jù)淘汰機(jī)制

由于Redis 天然就具有這兩個(gè)特征，Redis基于內(nèi)存操作的，且其具有完善的數(shù)據(jù)淘汰機(jī)制，十分適合作為緩存組件。

其中，基于內(nèi)存操作，容量可以為32-96GB，且操作時(shí)間平均為100ns，操作效率高。而且數(shù)據(jù)淘汰機(jī)制眾多，在Redis 4.0 后就有8種了促使Redis作為緩存可以適用很多場(chǎng)景。

那Redis緩存為什么需要數(shù)據(jù)淘汰機(jī)制呢？有哪8種數(shù)據(jù)淘汰機(jī)制呢？

數(shù)據(jù)淘汰機(jī)制

Redis緩存基于內(nèi)存實(shí)現(xiàn)的，則其緩存其容量是有限的，當(dāng)出現(xiàn)緩存被寫滿的情況，那么這時(shí)Redis該如何處理呢？

Redis對(duì)于緩存被寫滿的情況，Redis就需要緩存數(shù)據(jù)淘汰機(jī)制，通過(guò)一定淘汰規(guī)則將一些數(shù)據(jù)刷選出來(lái)刪除，讓緩存服務(wù)可再使用。那么Redis使用哪些淘汰策略進(jìn)行刷選刪除數(shù)據(jù)？

在Redis 4.0 之后，Redis 緩存淘汰策略6+2種，包括分成三大類：

• 不淘汰數(shù)據(jù)

• noeviction ，不進(jìn)行數(shù)據(jù)淘汰，當(dāng)緩存被寫滿后，Redis不提供服務(wù)直接返回錯(cuò)誤。

• 在設(shè)置過(guò)期時(shí)間的鍵值對(duì)中，

• volatile-random ，在設(shè)置過(guò)期時(shí)間的鍵值對(duì)中隨機(jī)刪除

• volatile-ttl ，在設(shè)置過(guò)期時(shí)間的鍵值對(duì)，基于過(guò)期時(shí)間的先后進(jìn)行刪除，越早過(guò)期的越先被刪除。

• volatile-lru ， 基于LRU(Least Recently Used) 算法篩選設(shè)置了過(guò)期時(shí)間的鍵值對(duì)， 最近最少使用的原則來(lái)篩選數(shù)據(jù)

• volatile-lfu ，使用 LFU( Least Frequently Used ) 算法選擇設(shè)置了過(guò)期時(shí)間的鍵值對(duì), 使用頻率最少的鍵值對(duì),來(lái)篩選數(shù)據(jù)。

• 在所有的鍵值對(duì)中，

• allkeys-random， 從所有鍵值對(duì)中隨機(jī)選擇并刪除數(shù)據(jù)

• allkeys-lru， 使用 LRU 算法在所有數(shù)據(jù)中進(jìn)行篩選

• allkeys-lfu， 使用 LFU 算法在所有數(shù)據(jù)中進(jìn)行篩選

Note: LRU( 最近最少使用，Least Recently Used)算法， LRU維護(hù)一個(gè)雙向鏈表 ，鏈表的頭和尾分別表示 MRU 端和 LRU 端，分別代表最近最常使用的數(shù)據(jù)和最近最不常用的數(shù)據(jù)。

LRU 算法在實(shí)際實(shí)現(xiàn)時(shí)，需要用鏈表管理所有的緩存數(shù)據(jù)，這會(huì)帶來(lái)額外的空間開銷。而且，當(dāng)有數(shù)據(jù)被訪問(wèn)時(shí)，需要在鏈表上把該數(shù)據(jù)移動(dòng)到 MRU 端，如果有大量數(shù)據(jù)被訪問(wèn)，就會(huì)帶來(lái)很多鏈表移動(dòng)操作，會(huì)很耗時(shí)，進(jìn)而會(huì)降低 Redis 緩存性能。

其中，LRU和LFU 基于Redis的對(duì)象結(jié)構(gòu)redisObject的lru和refcount屬性實(shí)現(xiàn)的:

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    // 對(duì)象最后一次被訪問(wèn)的時(shí)間
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
    // 引用計(jì)數(shù)                        * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

Redis的LRU會(huì)使用redisObject的lru記錄最近一次被訪問(wèn)的時(shí)間，隨機(jī)選取參數(shù)maxmemory-samples 配置的數(shù)量作為候選集合，在其中選擇 lru 屬性值最小的數(shù)據(jù)淘汰出去。

在實(shí)際項(xiàng)目中，那么該如何選擇數(shù)據(jù)淘汰機(jī)制呢？

• 優(yōu)先選擇 allkeys-lru算法，將最近最常訪問(wèn)的數(shù)據(jù)留在緩存中，提升應(yīng)用的訪問(wèn)性能。

• 有頂置數(shù)據(jù)使用 volatile-lru算法 ,頂置數(shù)據(jù)不設(shè)置緩存過(guò)期時(shí)間，其他數(shù)據(jù)設(shè)置過(guò)期時(shí)間，基于LRU 規(guī)則進(jìn)行篩選 。

在理解了Redis緩存淘汰機(jī)制后，來(lái)看看Redis作為緩存其有多少種模式呢？

Redis緩存模式

Redis緩存模式基于是否接收寫請(qǐng)求，可以分成只讀緩存和讀寫緩存：

只讀緩存：只處理讀操作，所有的更新操作都在數(shù)據(jù)庫(kù)中，這樣數(shù)據(jù)不會(huì)有丟失的風(fēng)險(xiǎn)。

• Cache Aside模式

讀寫緩存，讀寫操作都在緩存中執(zhí)行，出現(xiàn)宕機(jī)故障，會(huì)導(dǎo)致數(shù)據(jù)丟失。緩存回寫數(shù)據(jù)到數(shù)據(jù)庫(kù)有分成兩種同步和異步：

• 同步：訪問(wèn)性能偏低，其更加側(cè)重于保證數(shù)據(jù)可靠性

• Read-Throug模式

• Write-Through模式

• 異步：有數(shù)據(jù)丟失風(fēng)險(xiǎn)，其側(cè)重于提供低延遲訪問(wèn)

• Write-Behind模式

Cache Aside模式

查詢數(shù)據(jù)先從緩存讀取數(shù)據(jù)，如果緩存中不存在，則再到數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)，獲取到數(shù)據(jù)之后更新到緩存Cache中，但更新數(shù)據(jù)操作，會(huì)先去更新數(shù)據(jù)庫(kù)種的數(shù)據(jù)，然后將緩存種的數(shù)據(jù)失效。

而且Cache Aside模式會(huì)存在并發(fā)風(fēng)險(xiǎn)：執(zhí)行讀操作未命中緩存，然后查詢數(shù)據(jù)庫(kù)中取數(shù)據(jù)，數(shù)據(jù)已經(jīng)查詢到還沒放入緩存，同時(shí)一個(gè)更新寫操作讓緩存失效，然后讀操作再把查詢到數(shù)據(jù)加載緩存，導(dǎo)致緩存的臟數(shù)據(jù)。

Read/Write-Throug模式

查詢數(shù)據(jù)和更新數(shù)據(jù)都直接訪問(wèn)緩存服務(wù)，緩存服務(wù)同步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫(kù)。出現(xiàn)臟數(shù)據(jù)的概率較低，但是就強(qiáng)依賴緩存，對(duì)緩存服務(wù)的穩(wěn)定性有較大要求，但同步更新會(huì)導(dǎo)致其性能不好。

Write Behind模式

查詢數(shù)據(jù)和更新數(shù)據(jù)都直接訪問(wèn)緩存服務(wù)，但緩存服務(wù)使用異步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫(kù)（通過(guò)異步任務(wù)） 速度快，效率會(huì)非常高，但是數(shù)據(jù)的一致性比較差，還可能會(huì)有數(shù)據(jù)的丟失情況，實(shí)現(xiàn)邏輯也較為復(fù)雜。

在實(shí)際項(xiàng)目開發(fā)中根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景需求來(lái)進(jìn)行選擇緩存模式。那了解上述后，我們的應(yīng)用中為什么需要使用到redis緩存呢？

在應(yīng)用使用Redis緩存可以提高系統(tǒng)性能和并發(fā)，主要體現(xiàn)在

• 高性能：基于內(nèi)存查詢，KV結(jié)構(gòu)，簡(jiǎn)單邏輯運(yùn)算

• 高并發(fā)： MySQL 每秒只能支持2000左右的請(qǐng)求，Redis輕松每秒1W以上。讓80%以上查詢走緩存，20%以下查詢走數(shù)據(jù)庫(kù)，能讓系統(tǒng)吞吐量有很大的提高

雖然使用Redis緩存可以大大提升系統(tǒng)的性能，但是使用了緩存，會(huì)出現(xiàn)一些問(wèn)題，比如，緩存與數(shù)據(jù)庫(kù)雙向不一致、緩存雪崩等，對(duì)于出現(xiàn)的這些問(wèn)題該怎么解決呢？

使用緩存常見的問(wèn)題

使用了緩存，會(huì)出現(xiàn)一些問(wèn)題，主要體現(xiàn)在：

• 緩存與數(shù)據(jù)庫(kù)雙寫不一致

• 緩存雪崩: Redis 緩存無(wú)法處理大量的應(yīng)用請(qǐng)求，轉(zhuǎn)移到數(shù)據(jù)庫(kù)層導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增;

• 緩存穿透：訪問(wèn)數(shù)據(jù)不存在在Redis緩存中和數(shù)據(jù)庫(kù)中，導(dǎo)致大量訪問(wèn)穿透緩存直接轉(zhuǎn)移到數(shù)據(jù)庫(kù)導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增;

• 緩存擊穿：緩存無(wú)法處理高頻熱點(diǎn)數(shù)據(jù)，導(dǎo)致直接高頻訪問(wèn)數(shù)據(jù)庫(kù)導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增;

緩存與數(shù)據(jù)庫(kù)數(shù)據(jù)不一致

只讀緩存(Cache Aside模式)

對(duì)于只讀緩存(Cache Aside模式)， 讀操作都發(fā)生在緩存中，數(shù)據(jù)不一致只會(huì)發(fā)生在刪改操作上（新增操作不會(huì)，因?yàn)樾略鲋粫?huì)在數(shù)據(jù)庫(kù)處理），當(dāng)發(fā)生刪改操作時(shí)，緩存將數(shù)據(jù)中標(biāo)志為無(wú)效和更新數(shù)據(jù)庫(kù) 。因此在更新數(shù)據(jù)庫(kù)和刪除緩存值的過(guò)程中，無(wú)論這兩個(gè)操作的執(zhí)行順序誰(shuí)先誰(shuí)后，只要有一個(gè)操作失敗了就會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

讀到這里，這篇“java web實(shí)例分析”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過(guò)才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。