一般而言 Redis 在 Java Web 應(yīng)用中存在兩個(gè)主要的場景辅斟，一個(gè)是緩存常用的數(shù)據(jù)，另一個(gè)是在需要高速讀/寫的場合使用它快速讀/寫芦拿，比如一些需要進(jìn)行商品搶購和搶紅包的場合士飒。
由于在高并發(fā)的情況下，需要對數(shù)據(jù)進(jìn)行高速讀/寫的場景蔗崎，一個(gè)最為核心的問題是數(shù)據(jù)一致性和訪問控制酵幕。
緩存
在對數(shù)據(jù)庫的讀/寫操作中，現(xiàn)實(shí)的情況是讀操作的次數(shù)遠(yuǎn)超寫操作缓苛，一般是 1:9 到 3:7 的比例芳撒，所以需要讀的可能性是比寫的可能性多得多。
當(dāng)發(fā)送 SQL 去數(shù)據(jù)庫進(jìn)行讀取時(shí)未桥，數(shù)據(jù)庫就會(huì)去磁盤把對應(yīng)的數(shù)據(jù)索引回來笔刹，而索引磁盤是一個(gè)相對緩慢的過程。如果把數(shù)據(jù)直接放在運(yùn)行在內(nèi)存中的 Redis 服務(wù)器上冬耿，那么不需要去讀/寫磁盤了舌菜，而是直接讀取內(nèi)存，顯然速度會(huì)快得多淆党，并且會(huì)極大減輕數(shù)據(jù)庫的壓力酷师。
而使用內(nèi)存進(jìn)行存儲(chǔ)數(shù)據(jù)開銷也是比較大的讶凉，因?yàn)榇疟P可以是 TGB 級(jí)別，而且十分廉價(jià)山孔，內(nèi)存一般是幾百個(gè) GB 就相當(dāng)了不起了懂讯，所以內(nèi)存雖然高效但空間有限，價(jià)格也比磁盤高許多台颠，因此使用內(nèi)存代價(jià)較高褐望，并不是想存什么就存什么，因此我們應(yīng)該考慮有條件的存儲(chǔ)數(shù)據(jù)串前。
一般而言瘫里，存儲(chǔ)一些常用的數(shù)據(jù)，比如用戶登錄的信息荡碾；一些主要的業(yè)務(wù)信息谨读，比如銀行會(huì)存儲(chǔ)一些客戶基礎(chǔ)信息、銀行卡信息坛吁、最近交易信息等劳殖。一般而言在使用 Redis 存儲(chǔ)的時(shí)候，需要從 3 個(gè)方面進(jìn)行考慮拨脉。
- 業(yè)務(wù)數(shù)據(jù)常用嗎哆姻？命中率如何？如果命中率很低玫膀，就沒有必要寫入緩存矛缨。
- 該業(yè)務(wù)數(shù)據(jù)是讀操作多，還是寫操作多帖旨，如果寫操作多箕昭，頻繁需要寫入數(shù)據(jù)庫，也沒有必要使用緩存解阅。
- 業(yè)務(wù)數(shù)據(jù)大小如何盟广？如果要存儲(chǔ)幾百兆字節(jié)的文件，會(huì)給緩存帶來很大的壓力瓮钥，有沒有必要？
在考慮過這些問題后烹吵，如果覺得有必要使用緩存碉熄，那么就使用它。使用 Redis 作為緩存的讀取邏輯如圖 1 所示肋拔。
從圖 1 中可以知道以下兩點(diǎn)锈津。
- 當(dāng)?shù)谝淮巫x取數(shù)據(jù)的時(shí)候，讀取 Redis 的數(shù)據(jù)就會(huì)失敗凉蜂，此時(shí)會(huì)觸發(fā)程序讀取數(shù)據(jù)庫琼梆，把數(shù)據(jù)讀取出來性誉，并且寫入 Redis。
- 當(dāng)?shù)诙渭耙院笞x取數(shù)據(jù)時(shí)茎杂，就直接讀取 Redis错览，讀到數(shù)據(jù)后就結(jié)束了流程，這樣速度就大大提高了煌往。
從上面的分析可知倾哺，大部分的操作是讀操作，使用 Redis 應(yīng)對讀操作刽脖，速度就會(huì)十分迅速羞海，同時(shí)也降低了對數(shù)據(jù)庫的依賴，大大降低了數(shù)據(jù)庫的負(fù)擔(dān)曲管。
分析了讀操作的邏輯后却邓，下面再來分析寫操作的流程，如圖 2 所示院水。
從流程可以看出腊徙，更新或者寫入的操作，需要多個(gè) Redis 的操作衙耕。如果業(yè)務(wù)數(shù)據(jù)寫次數(shù)遠(yuǎn)大于讀次數(shù)沒有必要使用 Redis昧穿。如果是讀次數(shù)遠(yuǎn)大于寫次數(shù)，則使用 Redis 就有其價(jià)值了橙喘，因?yàn)閷懭?Redis 雖然要消耗一定的代價(jià)时鸵，但是其性能良好，相對數(shù)據(jù)庫而言厅瞎，幾乎可以忽略不計(jì)饰潜。
高速讀、寫場合
在互聯(lián)網(wǎng)的應(yīng)用中和簸，往往存在一些需要高速讀/寫的場合彭雾，比如商品的秒殺，搶紅包锁保，淘寶薯酝、京東的雙十一活動(dòng)或者春運(yùn)搶票等。
以上這類場合在一個(gè)瞬間成千上萬的請求就會(huì)達(dá)到服務(wù)器爽柒，如果使用的是數(shù)據(jù)庫吴菠，一個(gè)瞬間數(shù)據(jù)庫就需要執(zhí)行成千上萬的 SQL，很容易造成數(shù)據(jù)庫的瓶頸浩村，嚴(yán)重的會(huì)導(dǎo)致數(shù)據(jù)庫癱瘓做葵，造成 Java Web 系統(tǒng)服務(wù)崩潰。
在這樣的場合的應(yīng)對辦法往往是考慮異步寫入數(shù)據(jù)庫心墅，而在高速讀/寫的場合中單單使用 Redis 去應(yīng)對酿矢，把這些需要高速讀/寫的數(shù)據(jù)榨乎，緩存到 Redis 中，而在滿足一定的條件下瘫筐，觸發(fā)這些緩存的數(shù)據(jù)寫入數(shù)據(jù)庫中蜜暑。先看看一次請求操作的流程圖，如圖 3 所示严肪。
進(jìn)一步論述這個(gè)過程：
當(dāng)一個(gè)請求達(dá)到服務(wù)器，只是把業(yè)務(wù)數(shù)據(jù)先在 Redis 讀/寫驳糯，而沒有進(jìn)行任何對數(shù)據(jù)庫的操作篇梭，換句話說系統(tǒng)僅僅是操作 Redis 緩存，而沒有操作數(shù)據(jù)庫酝枢，這個(gè)速度就比操作數(shù)據(jù)庫要快得多恬偷，從而達(dá)到需要高速響應(yīng)的效果。
但是一般緩存不能持久化帘睦，或者所持久化的數(shù)據(jù)不太規(guī)范袍患，因此需要把這些數(shù)據(jù)存入數(shù)據(jù)庫，所以在一個(gè)請求操作完 Redis 的讀/寫后竣付，會(huì)去判斷該高速讀/寫的業(yè)務(wù)是否結(jié)束诡延。
這個(gè)判斷的條件往往就是秒殺商品剩余個(gè)數(shù)為 0，搶紅包金額為 0古胆，如果不成立肆良，則不會(huì)操作數(shù)據(jù)庫；如果成立逸绎，則觸發(fā)事件將 Redis 緩存的數(shù)據(jù)以批量的形式一次性寫入數(shù)據(jù)庫惹恃，從而完成持久化的工作。
假設(shè)面對的是一個(gè)商品秒殺的場景棺牧，從上面的流程看巫糙，一個(gè)用戶搶購商品，絕大部分的場合都是在操作內(nèi)存數(shù)據(jù)庫 Redis颊乘，而不是磁盤數(shù)據(jù)庫参淹，所以其性能更為優(yōu)越。只有在商品被搶購一空后才會(huì)觸發(fā)系統(tǒng)把 Redis 緩存的數(shù)據(jù)寫入數(shù)據(jù)庫磁盤中乏悄，這樣系統(tǒng)大部分的操作基于內(nèi)存承二，就能夠在秒殺的場合高速響應(yīng)用戶的請求，達(dá)到快速應(yīng)答纲爸。
而現(xiàn)實(shí)中這種需要高速響應(yīng)的系統(tǒng)會(huì)比上面的分析更復(fù)雜，因?yàn)檫@里沒有討論高并發(fā)下的數(shù)據(jù)安全和一致性問題妆够，沒有討論有效請求和無效請求识啦、事務(wù)一致性等諸多問題负蚊，這些將會(huì)在未來以獨(dú)立教程討論它。
