Redis 真得那麼好用嗎？

作者 | 初一

責編 | 胡巍巍

不管你是從事Python、Java、Go、PHP、Ruby等等......Redis都應該是一個比較熟悉的中間件。而大部分經常寫業務代碼的程序員，實際工作中或許只用到了set value、GetValue兩個操作，而對Redis缺乏一個整體的認識。今天就來對Redis的常見問題做一個總結。希望能夠幫助到大家。

Redis是什麼

Redis是一個開源的底層使用C語言編寫的Key-Value存儲資料庫。可用於緩存、事件發布訂閱、高速隊列等場景。而且支持豐富的數據類型：string（字元串）、Hash（哈希）、List（列表）、Set（無序集合）、Zset（sorted set：有序集合）。

Redis在項目中的應用場景：

1、緩存數據

最常用，對經常需要查詢且變動不是很頻繁的數據 常稱作熱點數據。

2、消息隊列

相當於消息訂閱系統，比如ActiveMQ、RocketMQ。如果對數據有較高一致性要求時，還是建議使用MQ。

3、計數器

比如統計點擊率、點贊率，Redis具有原子性，可以避免並發問題。

4、電商網站信息

大型電商平台初始化頁面數據的緩存。比如去哪兒網購買機票的時候首頁的價格和你點進去的價格會有差異。

5、熱點數據

比如新聞網站實時熱點、微博熱搜等，需要頻繁更新。總數據量比較大的時候直接從資料庫查詢會影響性能。

給個愛的理由

在單節點伺服器我們通常是這樣的。

隨著企業的發展、業務的擴展。面對海量的數據，直接使用MySQL會導致性能下降，數據的讀寫也會非常慢。於是我們就可以搭配緩存來處理海量數據。

於是現在我們是這樣的：

上圖只是簡述了緩存的作用，當數據繼續增大我們需要利用主從複製技術來達到讀寫分離。

資料庫層直接與緩存進行交互，如果緩存中有數據直接返回客戶端，如果沒有才會從MySQL中去查詢。從而減小了資料庫的壓力，提升了效率。

平時發布了一款新手機，會有搶購活動。同一時間段，服務端會收到很多的下單請求。

我們需要使用Redis的原子操作來實現這個「單線程」。首先我們把庫存存在一個列表中，假設有10件庫存，就往列表中push10個數，這個數沒有實際意義，僅僅只是代表10件庫存。

搶購開始後，每到來一個用戶，就從列表中POP一個數，表示用戶搶購成功。當列表為空時，表示已經被搶光了。因為列表的POP操作是原子的，即使有很多用戶同時到達，也是依次執行的。

題外話：還有的搶購是直接在前端頁面限制請求，這些請求直接被前端攔截，並沒有到後端伺服器。

Redis為什麼會這麼快？

1、Redis是純內存操作，需要的時候需要我們手動持久化到硬碟中。

2、Redis是單線程，從而避開了多線程中上下文頻繁切換的操作。

3、Redis數據結構簡單、對數據的操作也比較簡單。

4、使用底層模型不同，它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣，Redis直接自己構建了VM機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求

5、使用多路I/O復用模型，非阻塞I/O。

多路I/O復用

I/O多路復用技術，是為了解決進程或線程阻塞到某個I/O系統調用而出現的技術，可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒，就是這個文件描述符進行讀寫操作之前），能夠通知程序進行相應的讀寫操作。

Redis數據類型應用場景

前面提到了Redis支持五種豐富的數據類型，那麼在不同場景下我們該怎麼選擇呢？

String

字元串是最常用的數據類型，他能夠存儲任何類型的字元串，當然也包括二進位、JSON化的對象、甚至是Base64編碼之後的圖片。在Redis中一個字元串最大的容量為512MB，可以說是無所不能了。

Hash

常用作存儲結構化數據、比如論壇系統中可以用來存儲用戶的ID、昵稱、頭像、積分等信息。如果需要修改其中的信息，只需要通過Key取出Value進行反序列化修改某一項的值，再序列化存儲到Redis中。

對於Hash結構存儲，由於Hash結構會在單個Hash元素在不足一定數量時進行壓縮存儲，所以可以大量節約內存。這一點在String結構里是不存在的。

List

List的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩衝隊列等也都是用的這個數據結構。另外，可以利用lrange命令，做基於Redis的分頁功能，性能極佳，用戶體驗好。

Set

set對外提供的功能與List類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重複數據時，這個時候就可以選擇使用set。

Sorted Set

可以按照某個條件的權重進行排序，比如可以通過點擊數做出排行榜的數據應用。

Redis緩存的數據一致性

真正意義上來講資料庫的數據和緩存的數據是不可能一致的，數據分為最終一致和強一致兩類。如果業務中對數據的要求必須強一直那麼就不能使用緩存。緩存能做的只能保證數據的最終一致性。

我們能做的只能是儘可能地保證數據的一致性。不管是先刪庫再刪緩存還是先刪緩存再刪庫，都可能出現數據不一致的情況，因為讀和寫操作是並發的，我們沒辦法保證他們的先後順序。具體應對策略還是要根據業務需求來定，這裡就不贅述了。

Redis的過期和內存淘汰

Redis存儲數據時我們可以設置他的過期時間。但是這個Key是怎麼刪除的呢？

一開始我認為是定時刪除，後來發現並不是這樣，因為如果定時刪除，需要一個定時器來不斷地負責監控這個Key，雖然內存釋放了，但是非常消耗CPU資源。

Redis過期刪除採用的是定期刪除，默認是每100ms檢測一次，遇到過期的Key則進行刪除，這裡的檢測並不是順序檢測，而是隨機檢測。

那這樣會不會有漏網之魚？顯然Redis也考慮到了這一點，當我們去讀/寫一個已經過期的Key時，會觸發Redis的惰性刪除策略，直接回幹掉過期的Key。

內存淘汰是指用戶存儲的一部分Key是可以被Redis自動的刪除，從而會出現從緩存中查不到數據的情況。加入我們的伺服器內存為2G、但是隨著業務的發展緩存的數據已經超過2G了。

但是這並不影響我們程序的運行，因為操作系統的可見內存並不受物理內存的限制。物理內存不夠用沒關係，計算機會從硬碟中划出一片空間來作為虛擬內存。這就是Redis設計兩種應用場景的初衷：緩存、持久存儲。

緩存擊穿

緩存只是為了緩解資料庫壓力而添加的一層保護層，當從緩存中查詢不到我們需要的數據就要去資料庫中查詢了。如果被黑客利用，頻繁去訪問緩存中沒有的數據，那麼緩存就失去了存在的意義，瞬間所有請求的壓力都落在了資料庫上，這樣會導致資料庫連接異常。

解決方案：

1、後台設置定時任務，主動地去更新緩存數據。這種方案容易理解，但是當Key比較分散的時候，操作起來還是比較複雜的。

2、分級緩存。比如設置兩層緩存保護層，1級緩存失效時間短，2級緩存失效時間長。有請求過來優先從1級緩存中去查找，如果在1級緩存中沒有找到相應數據，則對該線程進行加鎖，這個線程再從資料庫中取到數據，更新至1級和2級緩存。其他線程則直接從2級線程中獲取。

3、提供一個攔截機制，內部維護一系列合法的Key值。當請求的Key不合法時，直接返回。

緩存雪崩

緩存雪崩就是指緩存由於某些原因（比如宕機、Cache服務掛了或者不響應）整體Crash掉了，導致大量請求到達後端資料庫，從而導致資料庫崩潰，整個系統崩潰、發生災難，也就是上面提到的緩存擊穿。

圖片來源自網路

如何避免雪崩：

1、給緩存加上一定區間內的隨機生效時間，不同的Key設置不同的失效時間，避免同一時間集體失效。

2、和緩存擊穿解決方案類似，做二級緩存，原始緩存失效時從拷貝緩存中讀取數據。

3、利用加鎖或者隊列方式避免過多請求同時對伺服器進行讀寫操作。

寫在最後

Redis的性能極高，讀的速度是110000次/s，寫的速度是81000次/s，支持事務，支持備份，豐富的數據類型。

任何事情都是兩面性，Redis也是有缺點的：

1、由於是內存資料庫，所以單台機器存儲的數據量是有限的，需要開發者提前預估，需要及時刪除不需要的數據。

2、當修改Redis的數據之後需要將持久化到硬碟的數據重新加入到內容中，時間比較久，這個時候Redis是無法正常運行的。

作者：初一，曾在知名互聯網公司擔任Java研發一職，項目帶頭人。2018年中旬轉行Python，熱愛爬蟲喜歡折騰新東西。Coding與樂趣同在。Talk is cheap，Show me the code。

聲明：本文為作者投稿，版權歸其個人所有。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！