【長文】帶你搞明白Redis

Redis，英文全稱是Remote Dictionary Server（遠程字典服務），是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。與MySQL數據庫不同的是，Redis的數據是存在內存中的。它的讀寫速度非常快，每秒可以處理超過10萬次讀寫操作。因此redis被廣泛應用于緩存，另外，Redis也經常用來做分布式鎖。除此之外，Redis支持事務、持久化、LUA 腳本、LRU 驅動事件、多種集群方案。

本文使用第一人稱來介紹Redis

一、概述

Redis，英文全稱是Remote Dictionary Server（遠程字典服務），是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。

與MySQL數據庫不同的是，Redis的數據是存在內存中的。它的讀寫速度非常快，每秒可以處理超過10萬次讀寫操作。因此redis被廣泛應用于緩存，另外，Redis也經常用來做分布式鎖。除此之外，Redis支持事務、持久化、LUA 腳本、LRU 驅動事件、多種集群方案。

redis

提及我的誕生，我與關系數據庫MySQL之間有著不解之緣。在我尚未降臨這個世界之前，MySQL歷經艱辛，伴隨著互聯網的飛速發展，它所承載的數據量日益龐大，用戶請求也如潮水般洶涌而至。每一次的用戶請求，都化作了對它無盡的讀寫挑戰，使得MySQL備受煎熬。特別是在“雙11”、“618”這樣的全民購物狂歡節，對MySQL而言，無疑是難熬的考驗時刻。

后來，MySQL向我透露了一個秘密。它告訴我，其實大多數的用戶請求都是讀取操作，而且往往都是對同一數據的反復查詢，這導致它不得不花費大量時間進行磁盤I/O操作，這無疑是一種巨大的資源浪費。

有人開始深思，是否可以借鑒CPU的工作原理，為數據庫也添加一個緩存機制呢？于是，我便應運而生，踏上了這個世界的舞臺。

自誕生之初，我便與MySQL結下了深厚的友誼。我們攜手并肩，共同出現在后端服務器的舞臺上。每當應用程序需要從MySQL查詢數據時，它們會首先在我這里進行登記。當再次需要這些數據時，它們會首先向我發出請求。如果我這里有它們所需的數據，它們便無需再勞煩MySQL；若我這里沒有，它們才會轉向MySQL尋求幫助。

如此，我便成為了MySQL的得力助手，與它共同應對著日益增長的數據挑戰。我們攜手前行，共同書寫著數據庫世界的輝煌篇章。
redis使用

二、支持的數據結構

大多數小伙伴都知道，為了方便使用，我支持以下這五種基本類型：

String（字符串）

Hash（哈希）

List（列表）

Set（集合）

zset（有序集合）

支持的數據結構

string

字符串最基礎的數據結構。字符串類型的值實際可以是字符串（簡單的字符串、復雜的字符串（例如JSON、XML））、數字（整數、浮點數），甚至是二進制（圖片、音頻、視頻），但是值最大不能超過512MB。

字符串主要有以下幾個典型使用場景：

緩存功能
計數
共享Session
限速

hash

哈希類型是指鍵值本身又是一個鍵值對結構。

哈希主要有以下典型應用場景：

緩存用戶信息
緩存對象

list

列表（list）類型是用來存儲多個有序的字符串。列表是一種比較靈活的數據結構，它可以充當棧和隊列的角色

list

列表主要有以下幾種使用場景：

消息隊列
文章列表

set

集合（set）類型也是用來保存多個的字符串元素，但和列表類型不一樣的是，集合中不允許有重復元素，并且集合中的元素是無序的。

集合主要有如下使用場景：

標簽（tag）
共同關注

sorted set

有序集合中的元素可以排序。但是它和列表使用索引下標作為排序依據不同的是，它給每個元素設置一個權重（score）作為排序的依據。

有序集合主要應用場景：

用戶點贊統計
用戶排序

我還有三種特殊的數據結構類型

Geospatial

Hyperloglog

Bitmap

因為我把登記的數據都記錄在內存中，不用去執行慢如蝸牛的I/O操作，所以找我要比找MySQL要省去了不少的時間呢。

可別小瞧這簡單的一個改變，我可為MySQL減輕了不小的負擔！隨著程序的運行，我緩存的數據越來越多，有相當部分時間我都給它擋住了用戶請求，這一下它可樂得清閑自在了！

有了我的加入，網絡服務的性能提升了不少，這都歸功于我為數據庫擋下了不少的事兒。

Redis快的原因

三、緩存過期 && 緩存淘汰

不過很快我發現事情不妙了，我緩存的數據都是在內存中，可是就算是在服務器上，內存的空間資源還是很有限的，不能無節制的這么存下去，我得想個辦法，不然吃棗藥丸。

不久，我想到了一個辦法：給緩存內容設置一個超時時間，具體設置多長交給應用程序們去設置，我要做的就是把過期了的內容從我里面刪除掉，及時騰出空間就行了。

緩存過期

超時時間有了，我該在什么時候去干這個清理的活呢？

最簡單的就是定期刪除，我決定100ms就做一次，一秒鐘就是10次！

我清理的時候也不能一口氣把所有過期的都給刪除掉，我這里面存了大量的數據，要全面掃一遍的話那不知道要花多久時間，會嚴重影響我接待新的客戶請求的！

緩存淘汰

時間緊任務重，我只好隨機選擇一部分來清理，能緩解內存壓力就行了。

就這樣過了一段日子，我發現有些個鍵值運氣比較好，每次都沒有被我的隨機算法選中，每次都能幸免于難，這可不行，這些長時間過期的數據一直霸占著不少的內存空間！氣抖冷！

我眼里可揉不得沙子！于是在原來定期刪除的基礎上，又加了一招：

那些原來逃脫我隨機選擇算法的鍵值，一旦遇到查詢請求，被我發現已經超期了，那我就絕不客氣，立即刪除。

這種方式因為是被動式觸發的，不查詢就不會發生，所以也叫惰性刪除！

可是，還是有部分鍵值，既逃脫了我的隨機選擇算法，又一直沒有被查詢，導致它們一直逍遙法外！而于此同時，可以使用的內存空間卻越來越少。

緩存刪除

而且就算退一步講，我能夠把過期的數據都刪除掉，那萬一過期時間設置的很長，還沒等到我去清理，內存就吃滿了，一樣要吃棗藥丸，所以我還得想個辦法。

我苦思良久，終于憋出了個大招：內存淘汰策略，這一次我要徹底解決問題！

我提供了8種淘汰策略供應用程序選擇，用于我遇到內存不足時該如何決策：

volatile-lru：從已設置過期時間的數據集中挑選最近最少使用的數據淘汰。
allkeys-lru：從數據集中挑選最近最少使用的數據淘汰
volatile-lfu：從已設置過期時間的數據集挑選使用頻率最低的數據淘汰。
allkeys-lfu：從數據集中挑選使用頻率最低的數據淘汰。
volatile-ttl：從已設置過期時間的數據集中挑選將要過期的數據淘汰。
volatile-random：從已設置過期時間的數據集中任意選擇數據淘汰。
allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰
no-enviction（驅逐）：禁止驅逐數據，這也是默認策略。意思是當內存不足以容納新入數據時，新寫入操作就會報錯，請求可以繼續進行，線上任務也不能持續進行，采用no-enviction策略可以保證數據不被丟失。

有了上面幾套組合拳，我再也不用擔心過期數據多了把空間撐滿的問題了~

我為了避免頻繁的觸發淘汰策略，每次會淘汰掉一批數據，淘汰的數據的大小其實是和置換的大小來確定的，如果置換的數據量大，淘汰的肯定也多。
客戶端執行一條新命令，導致數據庫需要增加數據（比如set key value）我會檢查內存使用，如果內存使用超過max memory，我就會按照置換策略刪除一些key

四、緩存穿透 && 布隆過濾器

我的日子過的還挺舒坦，不過MySQL大哥就沒我這么舒坦了，有時候遇到些煩人的請求，查詢的數據不存在，MySQL就要白忙活一場！不僅如此，因為不存在，我也沒法緩存啊，導致同樣的請求來了每次都要去讓MySQL白忙活一場。我作為緩存的價值就沒得到體現啦！這就是人們常說的緩存穿透。

緩存穿透

這一來二去，MySQL大哥忍不住了：“唉，兄弟，能不能幫忙想個辦法，把那些明知道不會有結果的查詢請求給我擋一下”

這時我想到了我的另外一個好朋友：布隆過濾器

布隆過濾器

我這位朋友別的本事沒有，就擅長從超大的數據集中快速告訴你查找的數據存不存在（悄悄告訴你，我的這位朋友有一點不靠譜，它告訴你存在的話不能全信，其實有可能是不存在的，不過它他要是告訴你不存在的話，那就一定不存在，同時他也不支持刪除元素）。它是一個連續的數據結構，每個存儲位存儲都是一個bit，即0或者1, 來標識數據是否存在。