不管你是從事Python、Java、Go、PHP、Ruby等等… Redis都應該是一個比較熟悉的中間件。而大部分經常寫業務代碼的程式員，實際工作中或許隻用到了set value、get value兩個操作。對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。
Sort 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、Python、Linux、資料庫、大資料、架構以及各方向電子書。公衆号内回複[禮包]即可領取。
長按二維碼加入我們一起成長吧~