一般而言Redis在Java Web 應用中存在兩個主要的場景，一個是快取常用的數據，另一個是在需要高速讀/寫的場合使用它快速讀取/寫入，例如一些需要進行商品搶購和搶紅包的場合。
由於在高並發的情況下，需要對資料進行高速讀取/寫入的場景，一個最為核心的問題是資料一致性和存取控制。
快取 （建議學習：#Redis影片教學）
在資料庫的讀取/寫入作業中，現實的情況是操作中，現實的情況是操作讀取操作的次數遠遠超寫操作，通常是1:9 到3:7 的比例，所以需要讀的可能性是比寫的可能性多很多。
當傳送 SQL 去資料庫進行讀取時，資料庫就會去磁碟把對應的資料索引回來，而索引磁碟是一個相對緩慢的過程。如果把資料直接放在運行在記憶體中的 Redis 伺服器上，那麼不需要去讀/寫磁碟了，而是直接讀取內存，顯然速度會快得多，並且會極大地減輕資料庫的壓力。
而使用記憶體進行儲存資料開銷也是比較大的，因為磁碟可以是TGB 級別，而且十分廉價，記憶體一般是幾百個GB 就相當了不起了，所以記憶體雖然高效但空間有限，價格也比磁碟高許多，因此使用記憶體代價較高，並不是想存什麼就存什麼，因此我們應該考慮有條件的儲存資料。
一般而言，儲存一些常用的數據，例如使用者登入的資訊；一些主要的業務訊息，例如銀行會儲存一些客戶基礎資訊、銀行卡資訊、最近交易資訊等。一般而言在使用 Redis 儲存的時候，需要從 3 個方面來考慮。
業務資料常用嗎？命中率如何？如果命中率很低，就沒有必要寫入快取。該業務資料是讀取操作多，還是寫入操作多，如果寫入操作多，頻繁需要寫入資料庫，也沒有必要使用快取。業務資料大小如何？如果要儲存幾百兆位元組的文件，會對快取造成很大的壓力，有沒有必要？
在考慮這些問題後，如果覺得有必要使用緩存，那就使用它。使用 Redis 作為快取的讀取邏輯如圖 1 所示。
從圖 1 可以知道以下兩點。
當第一次讀取資料的時候，讀取 Redis 的資料就會失敗，此時會觸發程式讀取資料庫，把資料讀取出來，並且寫入 Redis。
當第二次及以後讀取資料時，就直接讀取 Redis，讀到資料後就結束了流程，這樣速度就大大提高了。
從上面的分析可知，大部分的操作是讀取操作，使用 Redis 應對讀取操作，速度就會十分迅速，同時也降低了對資料庫的依賴，大大降低了資料庫的負擔。
分析了讀取操作的邏輯後，以下再來分析寫入操作的流程，如圖 2 所示。
從流程可以看出，更新或寫入的操作，需要多個 Redis 的操作。如果業務資料寫次數遠大於讀取次數沒有必要使用 Redis。
如果是讀取次數遠大於寫次數，則使用 Redis 就有其價值了，因為寫入 Redis 雖然要消耗一定的代價，但是其效能良好，相對資料庫而言，幾乎可以忽略不計。
高速讀/寫場合
在網路的應用中，往往存在一些需要高速讀/寫的場合，例如商品的秒殺，搶紅包，淘寶、京東的雙十一活動或春運搶票等。
以上這類場合在一個瞬間成千上萬的請求就會達到伺服器，如果使用的是資料庫，一個瞬間資料庫就需要執行成千上萬的SQL，很容易造成資料庫的瓶頸，嚴重的會導致資料庫癱瘓，造成Java Web 系統服務崩潰。
在這樣的場合的應對辦法往往是考慮異步寫入資料庫，而在高速讀/寫的場合中單單使用Redis 去應對，把這些需要高速讀/寫的數據，緩存到Redis 中，而在滿足一定的條件下，觸發這些快取的資料寫入資料庫中。先看看一次請求操作的流程圖，如圖 3 所示。
以上是java web中一般用redis來做什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
