【移動應用開發(fā)技術】java web實例分析

【移動應用開發(fā)技術】javaweb實例分析

本文在下為大家詳細介紹“javaweb實例分析”，內(nèi)容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“javaweb實例分析”文章能幫助大家解決疑惑，下面跟著在下的思路慢慢深入，一起來學習新知識吧。正文在實際的工作項目中，緩存成為高并發(fā)、高性能架構的關鍵組件，那么Redis為什么可以作為緩存使用呢？首先可以作為緩存的兩個主要特征：在分層系統(tǒng)中處于內(nèi)存/CPU具有訪問性能良好，緩存數(shù)據(jù)飽和，有良好的數(shù)據(jù)淘汰機制由于Redis天然就具有這兩個特征，Redis基于內(nèi)存操作的，且其具有完善的數(shù)據(jù)淘汰機制，十分適合作為緩存組件。其中，基于內(nèi)存操作，容量可以為32-96GB，且操作時間平均為100ns，操作效率高。而且數(shù)據(jù)淘汰機制眾多，在Redis4.0后就有8種了促使Redis作為緩存可以適用很多場景。那Redis緩存為什么需要數(shù)據(jù)淘汰機制呢？有哪8種數(shù)據(jù)淘汰機制呢？數(shù)據(jù)淘汰機制Redis緩存基于內(nèi)存實現(xiàn)的，則其緩存其容量是有限的，當出現(xiàn)緩存被寫滿的情況，那么這時Redis該如何處理呢？Redis對于緩存被寫滿的情況，Redis就需要緩存數(shù)據(jù)淘汰機制，通過一定淘汰規(guī)則將一些數(shù)據(jù)刷選出來刪除，讓緩存服務可再使用。那么Redis使用哪些淘汰策略進行刷選刪除數(shù)據(jù)？在Redis4.0之后，Redis緩存淘汰策略6+2種，包括分成三大類：不淘汰數(shù)據(jù)noeviction，不進行數(shù)據(jù)淘汰，當緩存被寫滿后，Redis不提供服務直接返回錯誤。在設置過期時間的鍵值對中，volatile-random，在設置過期時間的鍵值對中隨機刪除volatile-ttl，在設置過期時間的鍵值對，基于過期時間的先后進行刪除，越早過期的越先被刪除。volatile-lru，基于LRU(LeastRecentlyUsed)算法篩選設置了過期時間的鍵值對，最近最少使用的原則來篩選數(shù)據(jù)volatile-lfu，使用LFU(LeastFrequentlyUsed)算法選擇設置了過期時間的鍵值對,使用頻率最少的鍵值對,來篩選數(shù)據(jù)。在所有的鍵值對中，allkeys-random，從所有鍵值對中隨機選擇并刪除數(shù)據(jù)allkeys-lru，使用LRU算法在所有數(shù)據(jù)中進行篩選allkeys-lfu，使用LFU算法在所有數(shù)據(jù)中進行篩選Note:LRU(最近最少使用，LeastRecentlyUsed)算法，LRU維護一個雙向鏈表，鏈表的頭和尾分別表示MRU端和LRU端，分別代表最近最常使用的數(shù)據(jù)和最近最不常用的數(shù)據(jù)。LRU算法在實際實現(xiàn)時，需要用鏈表管理所有的緩存數(shù)據(jù)，這會帶來額外的空間開銷。而且，當有數(shù)據(jù)被訪問時，需要在鏈表上把該數(shù)據(jù)移動到MRU端，如果有大量數(shù)據(jù)被訪問，就會帶來很多鏈表移動操作，會很耗時，進而會降低Redis緩存性能。Note:LRU(最近最少使用，LeastRecentlyUsed)算法，LRU維護一個雙向鏈表，鏈表的頭和尾分別表示MRU端和LRU端，分別代表最近最常使用的數(shù)據(jù)和最近最不常用的數(shù)據(jù)。LRU算法在實際實現(xiàn)時，需要用鏈表管理所有的緩存數(shù)據(jù)，這會帶來額外的空間開銷。而且，當有數(shù)據(jù)被訪問時，需要在鏈表上把該數(shù)據(jù)移動到MRU端，如果有大量數(shù)據(jù)被訪問，就會帶來很多鏈表移動操作，會很耗時，進而會降低Redis緩存性能。其中，LRU和LFU基于Redis的對象結(jié)構redisObject的lru和refcount屬性實現(xiàn)的:typedef

struct

redisObject

{

unsigned

type:4;

unsigned

encoding:4;

//

對象最后一次被訪問的時間

unsigned

lru:LRU_BITS;

/*

LRU

time

(relative

to

global

lru_clock)

or

*

LFU

data

(least

significant

8

bits

frequency

//

引用計數(shù)

*

and

most

significant

16

bits

access

time).

*/

int

refcount;

void

*ptr;

}

robj;Redis的LRU會使用redisObject的lru記錄最近一次被訪問的時間，隨機選取參數(shù)maxmemory-samples配置的數(shù)量作為候選集合，在其中選擇lru屬性值最小的數(shù)據(jù)淘汰出去。在實際項目中，那么該如何選擇數(shù)據(jù)淘汰機制呢？優(yōu)先選擇allkeys-lru算法，將最近最常訪問的數(shù)據(jù)留在緩存中，提升應用的訪問性能。有頂置數(shù)據(jù)使用volatile-lru算法,頂置數(shù)據(jù)不設置緩存過期時間，其他數(shù)據(jù)設置過期時間，基于LRU規(guī)則進行篩選。在理解了Redis緩存淘汰機制后，來看看Redis作為緩存其有多少種模式呢？Redis緩存模式Redis緩存模式基于是否接收寫請求，可以分成只讀緩存和讀寫緩存：只讀緩存：只處理讀操作，所有的更新操作都在數(shù)據(jù)庫中，這樣數(shù)據(jù)不會有丟失的風險。CacheAside模式讀寫緩存，讀寫操作都在緩存中執(zhí)行，出現(xiàn)宕機故障，會導致數(shù)據(jù)丟失。緩存回寫數(shù)據(jù)到數(shù)據(jù)庫有分成兩種同步和異步：同步：訪問性能偏低，其更加側(cè)重于保證數(shù)據(jù)可靠性Read-Throug模式Write-Through模式異步：有數(shù)據(jù)丟失風險，其側(cè)重于提供低延遲訪問Write-Behind模式CacheAside模式查詢數(shù)據(jù)先從緩存讀取數(shù)據(jù)，如果緩存中不存在，則再到數(shù)據(jù)庫中讀取數(shù)據(jù)，獲取到數(shù)據(jù)之后更新到緩存Cache中，但更新數(shù)據(jù)操作，會先去更新數(shù)據(jù)庫種的數(shù)據(jù)，然后將緩存種的數(shù)據(jù)失效。而且CacheAside模式會存在并發(fā)風險：執(zhí)行讀操作未命中緩存，然后查詢數(shù)據(jù)庫中取數(shù)據(jù)，數(shù)據(jù)已經(jīng)查詢到還沒放入緩存，同時一個更新寫操作讓緩存失效，然后讀操作再把查詢到數(shù)據(jù)加載緩存，導致緩存的臟數(shù)據(jù)。Read/Write-Throug模式查詢數(shù)據(jù)和更新數(shù)據(jù)都直接訪問緩存服務，緩存服務同步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫。出現(xiàn)臟數(shù)據(jù)的概率較低，但是就強依賴緩存，對緩存服務的穩(wěn)定性有較大要求，但同步更新會導致其性能不好。WriteBehind模式查詢數(shù)據(jù)和更新數(shù)據(jù)都直接訪問緩存服務，但緩存服務使用異步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫（通過異步任務）

速度快，效率會非常高，但是數(shù)據(jù)的一致性比較差，還可能會有數(shù)據(jù)的丟失情況，實現(xiàn)邏輯也較為復雜。在實際項目開發(fā)中根據(jù)實際的業(yè)務場景需求來進行選擇緩存模式。那了解上述后，我們的應用中為什么需要使用到redis緩存呢？在應用使用Redis緩存可以提高系統(tǒng)性能和并發(fā)，主要體現(xiàn)在高性能：基于內(nèi)存查詢，KV結(jié)構，簡單邏輯運算高并發(fā)：Mysql每秒只能支持2000左右的請求，Redis輕松每秒1W以上。讓80%以上查詢走緩存，20%以下查詢走數(shù)據(jù)庫，能讓系統(tǒng)吞吐量有很大的提高雖然使用Redis緩存可以大大提升系統(tǒng)的性能，但是使用了緩存，會出現(xiàn)一些問題，比如，緩存與數(shù)據(jù)庫雙向不一致、緩存雪崩等，對于出現(xiàn)的這些問題該怎么解決呢？使用緩存常見的問題使用了緩存，會出現(xiàn)一些問題，主要體現(xiàn)在：緩存與數(shù)據(jù)庫雙寫不一致緩存雪崩:Redis緩存無法處理大量的應用請求，轉(zhuǎn)移到數(shù)據(jù)庫層導致數(shù)據(jù)庫層的壓力激增;緩存穿透：訪問數(shù)據(jù)不存在在Redis緩存中和數(shù)據(jù)庫中，導致大量訪問穿透緩存直接轉(zhuǎn)移到數(shù)據(jù)庫導致數(shù)據(jù)庫層的壓力激增;緩存擊穿：緩存無法處理高頻熱點數(shù)據(jù)，導致直接高頻訪問數(shù)據(jù)庫導致數(shù)據(jù)庫層的壓力激增;緩存與數(shù)據(jù)庫數(shù)據(jù)不一致只讀緩存(Ca