5. 緩存-Redis

文章目錄

前言
一、介紹
- 1. 簡介
- 2. 核心特點
二、應用場景
- 1. 應用場景
- 2. 數據類型作用場景
三、性能特性
- 1. 內存
- 2. 高性能數據結構
- 3. 單線程、多路復用
四、異步持久化機制
- 1. RDB（Redis Database）
- 2. AOF（Append-Only File）
- 3. 持久化機制
五、緩存問題
- 1. 概述
- 2. 緩存擊穿

前言

Redis?

Redis 是一個開源的、高性能的內存鍵值數據庫，以速度極快、支持豐富的數據結構而聞名，是現代應用架構中非常流行的組件。

一、介紹

1. 簡介

Redis 是一個開源的、高性能的內存鍵值數據庫，Redis 的鍵值對中的 key 就是字符串對象，而 value 就是指Redis的數據類型，可以是String，也可以是List、Hash、Set、 Zset 的數據類型。Redis通常被用作數據庫、緩存、消息中間件和實時數據處理引擎。它以速度極快、支持豐富的數據結構而聞名，是現代應用架構中非常流行的組件。

2. 核心特點

redis為什么這么快

純內存操作
單線程操作，避免了頻繁的上下文切換
采用了非阻塞I/O多路復用機制

內存存儲 (In-Memory):

數據主要存儲在內存 (RAM) 中，這是 Redis 速度驚人的根本原因（讀寫操作通常在微秒級別）。
它也提供可選的持久化機制，可以將數據異步或同步保存到磁盤，防止服務器重啟后數據丟失。

豐富的數據結構 (Data Structures):

不僅僅是簡單的 Key-Value 字符串！Redis 支持一共五種數據結構：

Strings: 最基本類型，可以存儲文本、數字、二進制數據（如圖片片段）。
Lists: 有序的元素集合，可在頭部或尾部插入/刪除，適合實現隊列、棧、時間線。
Sets: 無序的唯一元素集合，支持交集、并集、差集等操作，適合標簽、共同好友。
Sorted Sets (ZSets): 帶分數的有序唯一元素集合，元素按分數排序，完美適用于排行榜、優先級隊列。
Hashes: 存儲字段-值對的集合，非常適合表示對象（如用戶信息：field: name, value: “Alice”; field: age, value: 30）。
Bitmaps / HyperLogLogs / Geospatial Indexes: 特殊用途的數據結構，用于位操作、基數統計（去重計數）、地理位置計算等。

高性能與低延遲:

內存訪問 + 單線程架構 (核心命令執行是單線程，避免了鎖競爭) + 高效的網絡 I/O 模型 (epoll/kqueue) 使其擁有極高的吞吐量和極低的延遲。

持久化 (Persistence):

RDB (Redis Database File): 在指定時間間隔生成整個數據集的內存快照。恢復快，文件緊湊。適合備份和災難恢復。
AOF (Append-Only File): 記錄所有修改數據庫狀態的命令。更安全（最多丟失一秒數據），文件可讀性強，但文件通常更大，恢復可能比 RDB 慢。可以同時開啟或選擇其一。

原子操作與事務:

所有單條命令的執行都是原子的。
支持簡單的事務 (MULTI/EXEC)，可以將一組命令打包執行（但不支持回滾 - 命令語法錯誤會導致整個事務不執行，運行時錯誤不影響其他命令執行）。
Lua 腳本：可以執行復雜的、需要多個命令且保證原子性的操作。

還有像發布訂閱、集群架構等特性

二、應用場景

1. 應用場景

緩存 (Caching): 最常見的用途。將頻繁訪問的熱點數據（如數據庫查詢結果、頁面片段、會話信息）存儲在 Redis 中，顯著減輕后端數據庫壓力，提升應用響應速度。
會話存儲 (Session Store): 存儲用戶會話信息，易于在多服務器或微服務架構中實現會話共享。
排行榜/計數器 (Leaderboards / Counters): 利用 Sorted Sets 可以非常高效地實現實時排行榜。利用 INCR 等命令實現高并發下的計數器（如點贊數、瀏覽量）。
實時系統 (Real-time Systems):

消息隊列 (Message Queue)：利用 Lists 或 Streams (一種更強大的持久化消息隊列數據結構) 實現簡單的消息隊列。
實時分析：處理實時事件流（如用戶活動跟蹤、監控數據）。

地理空間應用 (Geospatial): 存儲地理位置坐標，執行附近位置查詢、距離計算等。
速率限制 (Rate Limiting): 限制用戶 API 調用頻率或操作次數。
分布式鎖 (Distributed Lock): 利用 Redis 的原子操作實現簡單的跨進程/跨機器的互斥鎖。

2. 數據類型作用場景

String可以用來做緩存、計數器、限流、分布式鎖、分布式Session等。
Hash可以用來存儲復雜對象。List可以用來做消息隊列、排行榜、計數器、最近訪問記錄等。
Set可以用來做標簽系統、好友關系、共同好友、排名系統、訂閱關系等。
Zset可以用來做排行榜、最近訪問記錄、計數器、好友關系等。
Geo可以用來做位置服務、物流配送、電商推薦、游戲地圖等。
HyperLogLog可以用來做用戶去重、網站UV統計、廣告點擊統計、分布式計算等。
Bitmaps可以用來做在線用戶數統計、黑白名單統計、布隆過濾器等。

三、性能特性

?Redis 可以達到極高的性能（官方測試讀速度約 11 萬次 / 秒，寫速度約 8 萬次 / 秒）！?

1. 內存

?基于內存操作?

Redis將所有數據存儲在內存中，避免了傳統數據庫的磁盤I/O瓶頸，內存的讀寫速度遠高于磁盤，這使得Redis能夠實現超高的響應速度。

內存的讀寫速度，和，磁盤讀寫速度的對比

最快情況下，固態硬盤速度，大致是內存速度的百分之一，
最慢情況下，機械硬盤速度，大致是內存速度的萬分之一，

內存讀寫速度可以達到每秒數百GB，在微秒級別，而磁盤（特別機械硬盤）讀寫速度通常只有數十MB，在毫秒級別, 是數千倍的差距。

對比與傳統的關系型數據庫比如說MySQL，需要從磁盤加載數據到內存緩沖區才能操作，Redis不需要這個步驟，就避免了磁盤 I/O 的延遲。

2. 高性能數據結構

?高效的數據結構?

Redis向我們用戶提供了value為string, list, hash, set, zset五種基本數據類型來使用，還有幾種高級的數據結構例如geo, bitmap, hyperloglog。本文只討論基本的數據類型了。

本節分析一下底層實現，這些數據類型底層實現有如下這么些：

sds（簡單動態字符串）
ziplist（壓縮列表）
linkedlist（雙端鏈表）
hashtable（字典）
skiplist（跳表）

這些底層結構能夠在內存中高效地存儲和操作數據，為Redis的快速性能提供了堅實的基礎。

數據結構和底層實現

3. 單線程、多路復用

單線程

Redis 的單線程設計是其高性能的核心支柱，但它并非字面意義上的“只有一個線程”。Redis 的工作線程（主線程）串行處理所有客戶端命令，但存在輔助線程處理異步任務。

為什么堅持核心單線程呢？這可能是一種取舍，如果是多線程的話，需要考慮共享數據結構需加鎖（如 Mutex）、線程上下文切換需要消耗 CPU 周期、線程安全編程難度高一些。

如果采用單線程的話，天然無鎖，可以保證操作的原子性；因為是單線程嘛，所以就沒有縣城上下文切換了；代碼就更簡單易懂了，也容易維護嘛。

單線程肯定會有不足的：比如說執行了慢命令，（如 KEYS *）會阻塞所有后續請求；單線程無法充分利用多核cpu。

所以可以得出：CPU 并不是Redis的瓶頸 → 避免鎖/切換開銷 → 單線程更高效

因為Redis使用內存存儲數據，所以數據訪問非常迅速，不會成為性能瓶頸。此外，Redis的數據操作大多數都是簡單的鍵值對操作，不包含復雜計算和邏輯，因而CPU開銷很小。相反，Redis的瓶頸在于內存的容量和網絡的帶寬，這些問題無法通過增加CPU核心來解決。

Redis 6.x開始引入了多線程，但是多線程僅僅是在處理網絡IO，Redis 核心命令執行依然是單線程，確保性能和一致性。

多路復用

那么，現在說一下Redis 的網絡 I/O 處理，采用事件驅動的 Reactor 模式，結合 I/O 多路復用技術和漸進式多線程優化：

Redis 采用 Reactor 模式作為網絡模型的基礎架構，在這一模式下，Redis 通過一個主事件循環（Event Loop）持續監聽并分發網絡事件。

首先，事件分發器：基于 I/O 多路復用技術（如 Linux 的 epoll）實現，負責監控所有客戶端連接的 Socket 文件描述符（FD）；

然后，事件處理器：為不同事件（如連接、讀、寫）綁定對應的回調函數。例如：連接事件觸發 accept 處理器，創建新客戶端連接；讀事件觸發命令請求處理器，解析并執行 Redis 命令；寫事件觸發響應回復處理器，將結果返回客戶端。

通過 I/O 多路復用，單一線程可同時監聽數萬個 Socket，僅當 Socket 真正發生讀寫事件時才觸發回調，避免了線程空轉和阻塞，這種設計使得 Redis 在單線程下仍能高效處理高并發請求，尤其適合內存操作快速完成的場景

盡管單線程模型簡化了數據一致性管理，但網絡 I/O 瓶頸在高并發場景下逐漸顯現。為此，Redis 從 6.0 版本開始引入漸進式多線程優化：新增的 I/O 線程僅負責網絡數據的讀取與發送，而命令解析與數據操作仍由主線程單線程執行，這種設計確保了核心數據操作的原子性，避免多線程競爭。

漸進式多線程優化

主要流程：

主線程接收新連接，將 Socket 分配至全局隊列；
I/O 線程池并行讀取請求數據并解析為命令（若啟用 io-threads-do-reads），或并行發送響應結果；
主線程按順序執行所有命令，再將結果寫入緩沖區供 I/O 線程發送
【用戶可通過 io-threads 參數設置線程數（建議為 CPU 核數的 1～1.5 倍），并通過 io-threads-do-reads 控制是否啟用讀并行化，在高并發網絡場景下，此優化可提升吞吐量 40%~50%，同時避免核心邏輯的鎖競爭】

四、異步持久化機制

單機的Redis速度已經獨步天下了，倘若遇到系統錯誤，導致Redis應用程序中斷了，由于數據是在內存里面，那不就全部丟失了嗎？這就需要說到Redis的持久化機制了。

Redis的持久化機制包含RDB和AOF兩種方式，其核心設計原則是最大化性能，因此持久化操作本質是異步的（主線程非阻塞）；

1. RDB（Redis Database）

機制

在Redis數據庫中RDB持久性以指定的時間間隔執行數據集的時間點快照，就是把某一時刻的數據和狀態以RDB文件的形式寫到磁盤上。這樣一來即使故障宕機，快照文件也不會丟失，當故障恢復時，再將硬盤快照文件直接讀到內存，這樣數據的可靠性也就得到了保證。
如下圖所示：

RDB

詳細來說，它是將內存中的數據以二進制格式生成全量快照（Snapshot），寫入 dump.rdb 文件，通過 fork 子進程完成持久化，主進程繼續處理請求，僅 fork 操作短暫阻塞（約 1-100ms）。

觸發

自動觸發（默認異步），在配置文件里面配置 save m n：如 save 900 1 表示 900 秒內至少 1 次鍵修改時觸發；從節點全量復制時自動觸發。
手動觸發，就需要命令的形式了，SAVE：同步阻塞主線程，生成快照（不推薦生產環境使用）；BGSAVE：異步生成快照，通過子進程完成（默認方式）。

影響

這種方式快速生成快照，對性能影響較小，此外呢，文件體積較小，適合備份和災難恢復。但是，如果是 Redis 服務器在兩次快照之間崩潰，可能會丟失部分數據

持久華-RDB

2. AOF（Append-Only File）

機制

AOF持久化是以日志的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來（讀操作不記錄）并以追加的方式寫在日志中。

在Redis服務重啟時，會根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。

工作原理如下圖所示：

AOF

在Redis執行寫操作時，不會立刻將寫操作寫入AOF文件中，而是先將寫命令保存在AOF緩存區，根據寫入策略將所有寫操作保存在AOF文件中。

詳細來說，它是將 Redis 執行的所有寫命令（如SET、INCR）追加到日志文件（默認名為appendonly.aof），同時在AOF 文件過大時，通過BGREWRITEAOF命令對日志進行瘦身（合并重復命令）：創建一個新的AOF文件來替代現有的AOF文件，新舊兩個文件所保存的數據庫狀態是相同的，但新 AOF文件去掉老的冗余命令，通常體積會較舊AOF文件小很多，達到壓縮 AOF 文件體積的目的。

觸發

隨著寫入AOF內容的增加，AOF會根據規則進行命令的合并（重寫），從而起到AOF文件壓縮的目的，避免了文件膨脹。

重寫瘦身觸發方式：

手動：BGREWRITEAOF 命令。
自動：滿足 auto-aof-rewrite-percentage（默認 100%）和 auto-aof-rewrite-min-size（默認 64MB）條件時觸發。

影響

這個重寫操作是異步的嗎？Redis是利用子線程進行復制拷貝，總結來說就是一個拷貝，兩處日志。?復制過程不會卡主線程?，整個過程是讓子進程干活，主線程繼續服務用戶。

兩處日志分別指：
【1】主線程正常處理新操作，把命令記錄到? AOF 緩沖區，異步刷新到原來的AOF日志?里（比如每秒刷一次磁盤）?。
【2】同時，新操作還會被額外記錄到? AOF重做緩沖區?，等小弟整理完舊日志后，這些新操作會被追加到新的AOF文件里，保證數據不丟失?

那么AOF這種方式的異步點在哪里呢？

寫操作：主線程將命令追加到 aof_buf 內存緩沖區（非阻塞）
刷盤策略：根據配置異步刷盤
- appendfsync always # 同步寫盤（強一致，性能差）
- appendfsync everysec # 每秒異步刷盤（推薦-默認）
- appendfsync no # 依賴操作系統刷盤

持久華-AOF

這種持久化方式數據安全性高（最多丟失 1 秒數據），支持命令級恢復，但是文件體積大，恢復速度慢，因為是很多命令。

3. 持久化機制

那么Redis是采用哪種方式呢？是同時開啟 RDB 和 AOF，利用 RDB 的快速恢復能力和 AOF 的數據安全性，重啟時，優先加載RDB恢復數據，再重放AOF增量操作。

優勢：

在使用RDB備份時，Redis父進程實現持久化工作只需要派生一個將完成所有其余工作的子進程即可，這樣父進程不需要執行磁盤I/O或類似操作，從而最大限度提高Redis性能。

RDB主要用于大規模的數據恢復、需要定時備份、對數據完整性和一致性要求不高的情況下。

劣勢：
- 當Redis突然停止工作后，未進行快照備份的數據會導致丟失；
- 內存數據的全量同步，如果數據量太大會導致I/O嚴重影響服務器性能；
- RDB依賴于主進程的fork，在更大的數據集中，這可能會導致服務請求的瞬間延遲，fork的時候內存中的數據被克隆一份，導致2倍的膨脹性。

優勢：
- AOF有不同的寫入策略，默認是每秒執行寫入，其性能也是很好的，而且最多只能丟失一秒的數據；
- AOF日志是一個僅附加日志，不會出現尋道問題，不會在斷電時出現損壞問題，即使有損壞，也可以通過redis-check-aof對AOF文件進行修復；
- 當AOF文件過大，Redis能在后臺自動重寫AOF，起到AOF文件壓縮的目的，避免了文件膨脹；
- AOF文件內容易于理解，方便我們對其進行修改，從而達到我們想要的效果。
劣勢：
- AOF文件通常比相同數據集的等效RDB文件大；
- AOF運行效率要慢于RDB，每秒同步策略效率較好，不同步效率和RDB相同；

注意：AOF的優先級高于RDB，當AOF和RDB同時使用時，Redis重啟時，只會加載AOF文件，不會加載RDB文件。

五、緩存問題

1. 概述

緩存問題Redis作為緩存的時候，會發生一些經典問題。下面就來分析一下：

緩存擊穿：單個熱點 Key 失效瞬間遭遇高并發。關鍵：單個熱點 Key 失效 + 高并發。倉庫門口堆放的一件特別搶手的熱門商品剛好賣完（緩存失效），一大群等著買它的人瞬間沖進倉庫搶購，把倉庫管理員（DB）累垮了。其他商品還能正常在門口買。
緩存穿透：查詢數據庫中根本不存在的數據。關鍵：數據不存在。請求必定穿透緩存訪問 DB。你要找的東西壓根不存在于倉庫（DB）里，每次都得翻遍倉庫確認沒有。倉庫管理員（DB）每次都得白忙活一趟。不管門口有沒有貨架（緩存），都得進倉庫。
緩存雪崩：大量 Key 同時失效或 Redis 集群整體不可用。關鍵：大規模失效 + 高并發。倉庫門口堆放的很多常用物品（緩存）在同一時間被清空了（同時失效），所有人（請求）涌進倉庫（數據庫）找東西，把倉庫擠爆了，并且因為倉庫癱瘓，導致整個商場（系統）停擺。

解決方面可以來一個兜底措施：比如說熔斷降級，來防止數據庫崩潰和雪崩擴散；服務限流來控制流量洪峰、從而也可以保護數據庫。

2. 緩存擊穿

問題描述

緩存擊穿是指一個訪問量非常大（熱點）的緩存 Key，在它過期失效（Expire）的瞬間，大量并發的請求同時發現緩存失效（Cache Miss），這些請求會擊穿緩存層，直接去查詢底層數據庫（如 MySQL）。

影響

這會導致數據庫在極短時間內承受巨大的、遠超其處理能力的請求壓力，可能導致數據庫響應變慢、連接耗盡甚至崩潰，進而引發整個系統的連鎖故障。
舉個例子，就比如倉庫門口堆放的一件特別搶手的熱門商品剛好賣完（緩存失效），一大群等著買它的人瞬間沖進倉庫搶購，把倉庫管理員（DB）累垮了。

緩存擊穿

特征

它是針對單個 Key 問題集中在某一個特定的熱點 Key 上，這個 Key 對應的數據訪問頻率非常高；
時機發生在在過期瞬間，在該 Key 設置的過期時間剛好到達的那一刻，這個時刻有高并發請求，同時這個時刻請求全打到數據庫了；
需要防止在緩存失效瞬間，大量請求同時訪問數據庫。

解決方案

方法一：互斥鎖

核心思想：既然是大量請求都直接訪問數據庫了，那我就在數據庫那一層加鎖，保證同一時刻只有一個線程訪問，這樣就減輕數據庫的壓力。

雙檢鎖

// 緩存擊穿，解決方式1---雙檢鎖
public GoodsgetGoodsDetailById(StringgoodsId) {// 1.先從緩存里面查GoodsgoodsObj= (Goods) valueOperations.get(RedisKey.GOODS_KEY+goodsId);// 2.緩存沒有再查數據庫if (goodsObj==null) {synchronized ( goodsId.intern() ) {goodsObj= (Goods) valueOperations.get(RedisKey.GOODS_KEY+goodsId);}if (goodsObj!=null) {returngoodsObj;}Goodsgoods=getDbGoodsById(goodsId);if (goods!=null) {valueOperations.set(RedisKey.GOODS_KEY+goodsId, goods);returngoods;}returnnull;}returngoodsObj;
}

加鎖檢查緩存（第一次檢查）：當用戶請求數據時，首先檢查緩存中是否存在該數據。
加鎖：如果緩存中沒有數據，那么走DB。但是，在嘗試從數據庫查詢數據之前，使用本地鎖（或者分布式鎖）來確保只有一個請求能夠執行數據庫查詢操作。
數據庫查詢：如果成功獲取到鎖，那么第二次檢查緩存，如果確實緩存中沒有數據，執行數據庫查詢操作，獲取最新的數據。
更新緩存：將查詢到的數據寫入緩存，并設置一個合理的過期時間。
釋放鎖：完成緩存更新后，釋放分布式鎖，以便其他請求可以繼續執行。
返回數據：將查詢到的數據返回給用戶。
處理其他請求：對于在等待鎖釋放期間到達的請求，它們可以直接從緩存中獲取數據，而不需要再次查詢數據庫。

上面的問題也很明顯，那就是假如查數據庫，寫入緩存這倆步驟，如果耗時過長，前面的請求會被一直阻塞住的。

結論：治標不治本

方法二：key不過期
- 永不過期：設置key的時候，不讓其過期，由于是永不過期的，故需要考慮更新這個key的值；
- 邏輯過期：緩存 Key 不設置過期時間（或設置一個很長的過期時間），讓其“永不過期”。但是我們可以在緩存 Value 中，額外存儲一個邏輯過期時間戳（例如 {value: obj, expireTime: 12345678910}），當應用讀取緩存時，檢查 Value 中的邏輯過期時間戳，如果未過期，直接返回數據；如果已過期，觸發一個異步任務（如放入消息隊列、啟動一個線程池任務都可以）去更新緩存。當前請求可以直接返回已過期的舊數據（業務允許短暫不一致）或嘗試獲取互斥鎖進行同步更新（類似方法 1）。

優點
此方法緩存 Key 永不失效，徹底避免“失效瞬間”的問題，用戶請求基本不受緩存更新影響，延遲低（直接返回舊數據或觸發異步更新）。

缺點
但是問題也是非常的明顯：首先就是業務要容忍數據的不一致性；需要實現異步更新機制（消息隊列、線程池），增加了設計的復雜性；其次呢，如果異步更新失敗或延遲過大，用戶可能長時間讀到舊數據；