Redis 概述
在我們日常的Java Web開發中，無不都是使用數據庫來進行數據的存儲，由於一般的系統任務中通常不會存在高併發的情況，所以這樣看起來並沒有什麼問題，可是一旦涉及大數據量的需求，比如一些商品搶購的情景，或者是主頁訪問量瞬間較大的時候，單一使用數據庫來保存數據的系統會因爲面向磁盤，磁盤讀/寫速度比較慢的問題而存在嚴重的性能弊端，一瞬間成千上萬的請求到來，需要系統在極短的時間內完成成千上萬次的讀/寫操作，這個時候往往不是數據庫能夠承受的，極其容易造成數據庫系統癱瘓，最終導致服務宕機的嚴重生產問題。
NoSQL 技術
爲了克服上述的問題，Java Web項目通常會引入NoSQL技術，這是一種基於內存的數據庫，並且提供一定的持久化功能。
Redis和MongoDB是當前使用最廣泛的NoSQL，而就Redis技術而言，它的性能十分優越，可以支持每秒十幾萬此的讀/寫操作，其性能遠超數據庫，並且還支持集羣、分佈式、主從同步等配置，原則上可以無限擴展，讓更多的數據存儲在內存中，更讓人欣慰的是它還支持一定的事務能力，這保證了高併發的場景下數據的安全和一致性。
Redis 在 Java Web 中的應用
Redis 在 Java Web 主要有兩個應用場景：
- 存儲 緩存 用的數據；
- 需要高速讀/寫的場合使用它快速讀/寫；
緩存
在日常對數據庫的訪問中，讀操作的次數遠超寫操作，比例大概在 1:9 到 3:7，所以需要讀的可能性是比寫的可能大得多的。當我們使用SQL語句去數據庫進行讀寫操作時，數據庫就會去磁盤把對應的數據索引取回來，這是一個相對較慢的過程。
如果我們把數據放在 Redis 中，也就是直接放在內存之中，讓服務端直接去讀取內存中的數據，那麼這樣速度明顯就會快上不少，並且會極大減小數據庫的壓力，但是使用內存進行數據存儲開銷也是比較大的，限於成本的原因，一般我們只是使用 Redis 存儲一些常用和主要的數據，比如用戶登錄的信息等。
一般而言在使用 Redis 進行存儲的時候，我們需要從以下幾個方面來考慮：
- 業務數據常用嗎？命中率如何？如果命中率很低，就沒有必要寫入緩存；
- 該業務數據是讀操作多，還是寫操作多？如果寫操作多，頻繁需要寫入數據庫，也沒有必要使用緩存；
- 業務數據大小如何？如果要存儲幾百兆字節的文件，會給緩存帶來很大的壓力，這樣也沒有必要；
在考慮了這些問題之後，如果覺得有必要使用緩存，那麼就使用它！使用 Redis 作爲緩存的讀取邏輯如下圖所示：
從上圖我們可以知道以下兩點：
- 當第一次讀取數據的時候，讀取 Redis 的數據就會失敗，此時就會觸發程序讀取數據庫，把數據讀取出來，並且寫入 Redis 中；
- 當第二次以及以後需要讀取數據時，就會直接讀取 Redis，讀到數據後就結束了流程，這樣速度就大大提高了。
從上面的分析可以知道，讀操作的可能性是遠大於寫操作的，所以使用 Redis 來處理日常中需要經常讀取的數據，速度提升是顯而易見的，同時也降低了對數據庫的依賴，使得數據庫的壓力大大減少。
分析了讀操作的邏輯，下面我們來看看寫操作的流程：
從流程可以看出，更新或者寫入的操作，需要多個 Redis 的操作，如果業務數據寫次數遠大於讀次數那麼就沒有必要使用 Redis。
關於使用內存存儲數據，我知道谷歌好像就是把所有互聯網的數據都存儲在內存條的，所以纔會有如此高質量、高效的搜索，但它畢竟是谷歌...
高速讀/寫的場合
在如今的互聯網中，越來越多的存在高併發的情況，比如天貓雙11、搶紅包、搶演唱會門票等，這些場合都是在某一個瞬間或者是某一個短暫的時刻有成千上萬的請求到達服務器，如果單純的使用數據庫來進行處理，就算不崩，也會很慢的，輕則造成用戶體驗極差用戶量流失，重則數據庫癱瘓，服務宕機，而這樣的場合都是不允許的！
所以我們需要使用 Redis 來應對這樣的高併發需求的場合，我們先來看看一次請求操作的流程圖：
我們來進一步闡述這個過程：
- 當一個請求到達服務器時，只是把業務數據在 Redis 上進行讀寫，而沒有對數據庫進行任何的操作，這樣就能大大提高讀寫的速度，從而滿足高速響應的需求；
- 但是這些緩存的數據仍然需要持久化，也就是存入數據庫之中，所以在一個請求操作完 Redis 的讀/寫之後，會去判斷該高速讀/寫的業務是否結束，這個判斷通常會在秒殺商品爲0，紅包金額爲0時成立，如果不成立，則不會操作數據庫；如果成立，則觸發事件將 Redis 的緩存的數據以批量的形式一次性寫入數據庫，從而完成持久化的工作。
作者：我沒有三顆心臟
鏈接：https://www.jianshu.com/p/56999f2b8e3b
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
