一般而言 Redis 在 Java Web 應(yīng)用中存在兩個主要的場景，一個是緩存常用的數(shù)據(jù)，另一個是在需要高速讀/寫的場合使用它快速讀/寫，比如一些需要進行商品搶購和搶紅包的場合。

由于在高并發(fā)的情況下，需要對數(shù)據(jù)進行高速讀/寫的場景，一個最為核心的問題是數(shù)據(jù)一致性和訪問控制。

緩存

在對數(shù)據(jù)庫的讀/寫操作中，現(xiàn)實的情況是讀操作的次數(shù)遠超寫操作，一般是 1:9 到 3:7 的比例，所以需要讀的可能性是比寫的可能性多得多。

當(dāng)發(fā)送 SQL 去數(shù)據(jù)庫進行讀取時，數(shù)據(jù)庫就會去磁盤把對應(yīng)的數(shù)據(jù)索引回來，而索引磁盤是一個相對緩慢的過程。如果把數(shù)據(jù)直接放在運行在內(nèi)存中的 Redis 服務(wù)器上，那么不需要去讀/寫磁盤了，而是直接讀取內(nèi)存，顯然速度會快得多，并且會極大減輕數(shù)據(jù)庫的壓力。

而使用內(nèi)存進行存儲數(shù)據(jù)開銷也是比較大的，因為磁盤可以是 TGB 級別，而且十分廉價，內(nèi)存一般是幾百個 GB 就相當(dāng)了不起了，所以內(nèi)存雖然高效但空間有限，價格也比磁盤高許多，因此使用內(nèi)存代價較高，并不是想存什么就存什么，因此我們應(yīng)該考慮有條件的存儲數(shù)據(jù)。

一般而言，存儲一些常用的數(shù)據(jù)，比如用戶登錄的信息；一些主要的業(yè)務(wù)信息，比如銀行會存儲一些客戶基礎(chǔ)信息、銀行卡信息、最近交易信息等。一般而言在使用 Redis 存儲的時候，需要從 3 個方面進行考慮。

1. 業(yè)務(wù)數(shù)據(jù)常用嗎？命中率如何？如果命中率很低，就沒有必要寫入緩存。
2. 該業(yè)務(wù)數(shù)據(jù)是讀操作多，還是寫操作多，如果寫操作多，頻繁需要寫入數(shù)據(jù)庫，也沒有必要使用緩存。
3. 業(yè)務(wù)數(shù)據(jù)大小如何？如果要存儲幾百兆字節(jié)的文件，會給緩存帶來很大的壓力，有沒有必要？

在考慮過這些問題后，如果覺得有必要使用緩存，那么就使用它。使用 Redis 作為緩存的讀取邏輯如圖 1 所示。

圖1 Redis的緩存應(yīng)用

從圖 1 中可以知道以下兩點。

• 當(dāng)?shù)谝淮巫x取數(shù)據(jù)的時候，讀取 Redis 的數(shù)據(jù)就會失敗，此時會觸發(fā)程序讀取數(shù)據(jù)庫，把數(shù)據(jù)讀取出來，并且寫入 Redis。
• 當(dāng)?shù)诙渭耙院笞x取數(shù)據(jù)時，就直接讀取 Redis，讀到數(shù)據(jù)后就結(jié)束了流程，這樣速度就大大提高了。

從上面的分析可知，大部分的操作是讀操作，使用 Redis 應(yīng)對讀操作，速度就會十分迅速，同時也降低了對數(shù)據(jù)庫的依賴，大大降低了數(shù)據(jù)庫的負擔(dān)。

分析了讀操作的邏輯后，下面再來分析寫操作的流程，如圖 2 所示。

圖2 寫操作的流程

從流程可以看出，更新或者寫入的操作，需要多個 Redis 的操作。如果業(yè)務(wù)數(shù)據(jù)寫次數(shù)遠大于讀次數(shù)沒有必要使用 Redis。如果是讀次數(shù)遠大于寫次數(shù)，則使用 Redis 就有其價值了，因為寫入 Redis 雖然要消耗一定的代價，但是其性能良好，相對數(shù)據(jù)庫而言，幾乎可以忽略不計。

高速讀、寫場合

在互聯(lián)網(wǎng)的應(yīng)用中，往往存在一些需要高速讀/寫的場合，比如商品的秒殺，搶紅包，淘寶、京東的雙十一活動或者春運搶票等。

以上這類場合在一個瞬間成千上萬的請求就會達到服務(wù)器，如果使用的是數(shù)據(jù)庫，一個瞬間數(shù)據(jù)庫就需要執(zhí)行成千上萬的 SQL，很容易造成數(shù)據(jù)庫的瓶頸，嚴(yán)重的會導(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 所示。

圖3 Redis在高速讀、寫場合的應(yīng)用

進一步論述這個過程：
當(dāng)一個請求達到服務(wù)器，只是把業(yè)務(wù)數(shù)據(jù)先在 Redis 讀/寫，而沒有進行任何對數(shù)據(jù)庫的操作，換句話說系統(tǒng)僅僅是操作 Redis 緩存，而沒有操作數(shù)據(jù)庫，這個速度就比操作數(shù)據(jù)庫要快得多，從而達到需要高速響應(yīng)的效果。

但是一般緩存不能持久化，或者所持久化的數(shù)據(jù)不太規(guī)范，因此需要把這些數(shù)據(jù)存入數(shù)據(jù)庫，所以在一個請求操作完 Redis 的讀/寫后，會去判斷該高速讀/寫的業(yè)務(wù)是否結(jié)束。

這個判斷的條件往往就是秒殺商品剩余個數(shù)為 0，搶紅包金額為 0，如果不成立，則不會操作數(shù)據(jù)庫；如果成立，則觸發(fā)事件將 Redis 緩存的數(shù)據(jù)以批量的形式一次性寫入數(shù)據(jù)庫，從而完成持久化的工作。

假設(shè)面對的是一個商品秒殺的場景，從上面的流程看，一個用戶搶購商品，絕大部分的場合都是在操作內(nèi)存數(shù)據(jù)庫 Redis，而不是磁盤數(shù)據(jù)庫，所以其性能更為優(yōu)越。只有在商品被搶購一空后才會觸發(fā)系統(tǒng)把 Redis 緩存的數(shù)據(jù)寫入數(shù)據(jù)庫磁盤中，這樣系統(tǒng)大部分的操作基于內(nèi)存，就能夠在秒殺的場合高速響應(yīng)用戶的請求，達到快速應(yīng)答。

而現(xiàn)實中這種需要高速響應(yīng)的系統(tǒng)會比上面的分析更復(fù)雜，因為這里沒有討論高并發(fā)下的數(shù)據(jù)安全和一致性問題，沒有討論有效請求和無效請求、事務(wù)一致性等諸多問題，這些將會在未來以獨立教程討論它。