一般而言Redis在Javaweb應用中存在兩個主要的場景,一個是緩存常用的數據,另一個是在需要高速讀/寫的場合使用它快速讀/寫,比如一些需要進行商品搶購和搶紅包的場合.
一,緩存
在對數據庫的讀／寫操作中，現實的情況是讀操作的次數遠超寫操作， 一般是1 : 9 到3 : 7 的比例，所以需要讀的可能性是比寫的可能性多得多。當發送S QL 去數據庫進行讀取時，數據庫就會去磁盤把對應的數據索引回來， 而索引磁盤是一個相對緩慢的過程。如果把數據直接放在運行在內存中的Redis 服務器上，那么不需要去讀／寫磁盤了，而是直接讀取內存，顯然速度會快得多，並且會極大減輕數據庫的壓力。
而使用內存進行存儲數據開銷也是比較大的，因為磁盤可以是TGB 級別，而且十分廉價，內存一般是幾百個GB 就相當了不起了，所以內存雖然高效但空間有限，價格也比磁盤高許多，因此使用內存代價較高，並不是想存什么就存什么，因此我們應該考慮有條件的存儲數據。一般而言，存儲一些常用的數據，比如用戶登錄的信息： 一些主要的業務信息，比如銀行會存儲一些客戶基礎信息、銀行卡信息、最近交易信息等。一般而言在使用
Red is 存儲的時候，需要從3 個方面進行考慮。
·業務數據常用嗎？命中率如何？如果命中率很低，就沒有必要寫入緩存。
· 該業務數據是讀操作多，還是寫操作多，如果寫操作多，頻繁需要寫入數據庫，也沒有必要使用緩存。
·業務數據大小如何？如果要存儲幾百兆字節的文件，會給緩存帶來很大的壓力，有沒有必要？
在考慮過這些問題后，如果覺得有必要使用緩存，那么就使用它。
從圖17-1 中可以知道以下兩點。
· 當第一次讀取數據的時候，讀取Redis 的數據就會失敗，此時會觸發程序讀取數據庫，把數據讀取出來，並且寫入Redis 。
． 當第二次及以后讀取數據時，就直接讀取Redis ， 讀到數據后就結束了流程，這樣速度就大大提高了。
從上面的分析可知，大部分的操作是讀操作，使用Redis 應對讀操作，速度就會十分迅速，同時也降低了對數據庫的依賴， 大大降低了數據庫的負擔。
分析了讀操作的邏輯后，下面再來分析寫操作的流程，如圖17-2所示
從流程可以看出，更新或者寫入的操作，需要多個Redis 的操作。如果業務數據寫次數遠大於讀次數沒有必要使用Redis 。如果是讀次數遠大於寫次數， 則使用Redis 就有其價值了，因為寫入Redis 雖然要消耗一定的代價，但是其性能良好，相對數據庫而言，幾乎可以忽略不計。
二 高速讀/寫場合
在互聯網的應用中，往往存在一些需要高速讀／寫的場合，比如商品的秒殺，搶紅包，淘寶、京東的雙十一活動或者春運搶票等。這類場合在一個瞬間成千上萬的請求就會達到服務器，如果使用的是數據庫， 一個瞬間數據庫就需要執行成千上萬的SQL ，很容易造成數據庫的瓶頸，嚴重的會導致數據庫癱瘓，造成Java Web 系統服務崩潰。
在這樣的場合的應對辦法往往是考慮異步寫入數據庫，而在高速讀／寫的場合中單單使用Redis 去應對， 把這些需要高速讀／寫的數據， 緩存到Redis 中，而在滿足一定的條件下，觸發這些緩存的數據寫入數據庫中。先看看一次請求操作的流程圖，如圖17-3 所示。
進一步論述這個過程： 當一個請求達到服務器，只是把業務數據先在Redi s 讀／寫，而沒有進行任何對數據庫的操作，換句話說系統僅僅是操作Redis 緩存，而沒有操作數據庫，這個速度就比操作數據庫要快得多，從而達到需要高速響應的效果。但是一般緩存不能持久化，或者所持久化的數據不太規范，因此需要把這些數據存入數據庫，所以在一個請求操作完Red is 的讀／寫后，會去判斷該高速讀／寫的業務是否結束。這個判斷的條件往往就是秒殺商品剩余個數為0 ，搶紅包金額為0 ，如果不成立，則不會操作數據庫；如果成立，則觸發事件將Redis 緩存的數據以批量的形式一次性寫入數據庫，從而完成持久化的工作。
假設面對的是一個商品秒殺的場景，從上面的流程看， 一個用戶搶購商品，絕大部分的場合都是在操作內存數據庫Re dis ， 而不是磁盤數據庫，所以其性能更為優越。只有在商品被搶購一空后才會觸發系統把Red is 緩存的數據寫入數據庫磁盤中， 這樣系統大部分的操作基於內存，就能夠在秒殺的場合高速響應用戶的請求，達到快速應答。
而現實中這種需要高速響應的系統會比上面的分析更復雜， 因為這里沒有討論高並發下的數據安全和一致性問題，沒有討論有效請求和無效請求、事務一致性等諸多問題，這些將會在未來以獨立章節討論它。