Redis能抗住百萬并發的秘密

作者：蘇三 2025-09-11 09:11:36

數據庫 Redis

有些小伙伴在工作中可能遇到過這樣的場景：系統訪問量一上來，數據庫就扛不住了，這時候大家第一時間想到的就是Redis。但你有沒有想過，為什么Redis能夠承受如此高的并發量？它的底層到底做了什么優化？

今天想和大家深入聊聊Redis為什么能夠輕松抗住百萬級別的并發請求。

有些小伙伴在工作中可能遇到過這樣的場景：系統訪問量一上來，數據庫就扛不住了，這時候大家第一時間想到的就是Redis。

但你有沒有想過，為什么Redis能夠承受如此高的并發量？它的底層到底做了什么優化？

今天我們就從淺入深，一步步揭開Redis高性能的神秘面紗。

1. Redis高并發的核心架構

1.1 單線程模型的威力

有些小伙伴可能會疑惑：Redis是單線程的，為什么還能支持這么高的并發？

這里需要澄清一個概念，Redis的"單線程"指的是網絡IO和鍵值對讀寫是由一個線程來完成的，但Redis的整個系統并不是只有一個線程。

圖片

為什么單線程反而更快？

避免了線程切換的開銷：多線程環境下，CPU需要在不同線程間切換，這個過程需要保存和恢復線程上下文，開銷很大。
避免了鎖競爭：單線程模型下，不需要考慮線程安全問題，避免了各種鎖的開銷。
CPU緩存友好：單線程執行時，CPU緩存命中率更高，減少了內存訪問延遲。

讓我們看一個簡單的對比：

// 多線程模式下的偽代碼
public class MultiThreadRedis {
    private final Object lock = new Object();
    private Map<String, String> data = new HashMap<>();
    
    public String get(String key) {
        synchronized(lock) {  // 需要加鎖
            return data.get(key);
        }
    }
    
    public void set(String key, String value) {
        synchronized(lock) {  // 需要加鎖
            data.put(key, value);
        }
    }
}

// Redis單線程模式下的偽代碼
public class SingleThreadRedis {
    private Map<String, String> data = new HashMap<>();
    
    public String get(String key) {
        return data.get(key);  // 無需加鎖
    }
    
    public void set(String key, String value) {
        data.put(key, value);  // 無需加鎖
    }
}

1.2 事件驅動模型

Redis采用了事件驅動的架構，基于Reactor模式實現。

這種模式的核心思想是：用一個線程來處理多個連接的IO事件。

圖片

事件驅動的優勢：

高效的IO多路復用：一個線程可以同時監聽多個socket連接
非阻塞IO：不會因為某個連接的IO操作而阻塞整個程序
內存占用少：相比多線程模型，節省了大量線程棧空間

2. 內存數據結構的極致優化

2.1 高效的數據結構設計

Redis的高性能很大程度上得益于其精心設計的內存數據結構。

每種數據類型都有多種底層實現，Redis會根據數據的特點自動選擇最優的存儲方式。

讓我們深入了解幾個關鍵的數據結構：

2.1.1 SDS (Simple Dynamic String)

有些小伙伴可能不知道，Redis并沒有直接使用C語言的字符串，而是自己實現了SDS。

// Redis SDS結構
struct sdshdr {
    int len;        // 字符串長度
    int free;       // 未使用空間長度
    char buf[];     // 字符串內容
};

SDS的優勢：

O(1)時間復雜度獲取長度：直接讀取len字段
預分配空間：減少內存重新分配次數
二進制安全：可以存儲任意二進制數據
兼容C字符串函數：以空字符結尾

2.1.2 跳躍表 (Skip List)

跳躍表是Redis中有序集合的核心數據結構，它的查找效率可以達到O(log N)。

圖片

跳躍表的查找過程：

// 跳躍表查找偽代碼
public Node search(int target) {
    Node current = header;
    
    // 從最高層開始查找
    for (int level = maxLevel; level >= 0; level--) {
        // 在當前層向右移動，直到下一個節點大于目標值
        while (current.forward[level] != null && 
               current.forward[level].value < target) {
            current = current.forward[level];
        }
    }
    
    // 移動到下一個節點
    current = current.forward[0];
    
    if (current != null && current.value == target) {
        return current;
    }
    returnnull;
}

2.2 內存優化策略

2.2.1 壓縮列表 (ziplist)

當Hash、List、ZSet的元素較少時，Redis會使用壓縮列表來節省內存。

圖片

壓縮列表的優勢：

內存緊湊：所有元素連續存儲，減少內存碎片
緩存友好：連續內存訪問，CPU緩存命中率高
節省指針開銷：不需要存儲指向下一個元素的指針

2.2.2 整數集合 (intset)

當Set中只包含整數元素時，Redis使用整數集合來存儲。

// 整數集合結構
typedef struct intset {
    uint32_t encoding;  // 編碼方式
    uint32_t length;    // 元素數量
    int8_t contents[];  // 元素數組
} intset;

編碼方式自動升級：

// 整數集合編碼升級示例
public class IntSetExample {
    // 初始狀態：所有元素都是16位整數
    // encoding = INTSET_ENC_INT16
    // contents = [1, 2, 3, 4, 5]
    
    // 添加一個32位整數
    public void addLargeNumber() {
        // 自動升級為32位編碼
        // encoding = INTSET_ENC_INT32
        // 重新分配內存，轉換所有現有元素
    }
}

3. 網絡IO優化

3.1 IO多路復用技術

Redis在不同操作系統上使用不同的IO多路復用技術：

Linux: epoll
macOS/FreeBSD: kqueue
Windows: select

圖片

epoll的優勢：

事件驅動：只有當socket有事件時才會通知應用程序
高效輪詢：不需要遍歷所有文件描述符
支持邊緣觸發：減少系統調用次數

3.2 客戶端輸出緩沖區

Redis為每個客戶端維護輸出緩沖區，避免慢客戶端影響整體性能。

圖片

緩沖區配置示例：

# redis.conf配置
# 普通客戶端緩沖區限制
client-output-buffer-limit normal 0 0 0

# 從服務器緩沖區限制  
client-output-buffer-limit replica 256mb 64mb 60

# 發布訂閱客戶端緩沖區限制
client-output-buffer-limit pubsub 32mb 8mb 60

4. 內存管理優化

4.1 內存分配器選擇

Redis支持多種內存分配器，默認使用jemalloc，這是一個專門為多線程應用優化的內存分配器。

圖片

4.2 過期鍵刪除策略

Redis采用惰性刪除和定期刪除相結合的策略來處理過期鍵。

圖片

定期刪除算法：

// Redis定期刪除偽代碼
public void activeExpireCycle() {
    int maxIterations = 16; // 最大檢查數據庫數
    int maxChecks = 20;     // 每個數據庫最大檢查鍵數
    
    for (int i = 0; i < maxIterations; i++) {
        RedisDb db = server.db[i];
        int expired = 0;
        
        for (int j = 0; j < maxChecks; j++) {
            String key = db.expires.randomKey();
            if (key != null && isExpired(key)) {
                deleteKey(key);
                expired++;
            }
        }
        
        // 如果過期鍵比例小于25%，跳出循環
        if (expired < maxChecks / 4) {
            break;
        }
    }
}

5. 持久化優化

5.1 RDB持久化

RDB是Redis的默認持久化方式，它會在指定的時間間隔內生成數據集的時點快照。

圖片

RDB的優勢：

緊湊的文件格式：適合備份和災難恢復
快速重啟：恢復速度比AOF快
對性能影響小：使用子進程進行持久化

5.2 AOF持久化

AOF通過記錄服務器執行的所有寫操作命令來實現持久化。

圖片

AOF重寫優化：

// AOF重寫示例
public class AOFRewrite {
    // 原始AOF文件可能包含：
    // SET key1 value1
    // SET key1 value2  
    // SET key1 value3
    // DEL key2
    // SET key2 newvalue
    // LPUSH list a
    // LPUSH list b
    // LPUSH list c
    
    // 重寫后的AOF文件：
    // SET key1 value3
    // SET key2 newvalue  
    // LPUSH list c b a
    
    public void rewriteAOF() {
        // 遍歷所有數據庫
        for (RedisDb db : server.databases) {
            // 遍歷所有鍵
            for (String key : db.dict.keys()) {
                Object value = db.dict.get(key);
                // 根據值的類型生成對應的命令
                generateCommand(key, value);
            }
        }
    }
}

6. 集群和分片優化

6.1 Redis Cluster

Redis Cluster是Redis的官方集群解決方案，采用無中心化的架構。

圖片

哈希槽分配算法：

public class RedisClusterSlot {
    private static final int CLUSTER_SLOTS = 16384;
    
    public int calculateSlot(String key) {
        // 檢查是否有哈希標簽
        int start = key.indexOf('{');
        if (start != -1) {
            int end = key.indexOf('}', start + 1);
            if (end != -1 && end != start + 1) {
                key = key.substring(start + 1, end);
            }
        }
        
        // 計算CRC16校驗和
        int crc = crc16(key.getBytes());
        return crc % CLUSTER_SLOTS;
    }
    
    // CRC16算法實現
    private int crc16(byte[] data) {
        int crc = 0x0000;
        for (byte b : data) {
            crc ^= (b & 0xFF);
            for (int i = 0; i < 8; i++) {
                if ((crc & 0x0001) != 0) {
                    crc = (crc >> 1) ^ 0xA001;
                } else {
                    crc = crc >> 1;
                }
            }
        }
        return crc & 0xFFFF;
    }
}

6.2 分片策略

有些小伙伴在設計分片策略時，可能會遇到數據傾斜的問題。

Redis提供了多種分片方式：

圖片

7. 性能監控和調優

7.1 關鍵性能指標

圖片

性能監控命令：

# 查看Redis信息
INFO all

# 監控實時命令
MONITOR

# 查看慢查詢日志
SLOWLOG GET 10

# 查看客戶端連接
CLIENT LIST

# 查看內存使用情況
MEMORY USAGE keyname

# 查看延遲統計
LATENCY LATEST

7.2 性能調優建議

內存優化：

# redis.conf優化配置

# 啟用內存壓縮
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

list-max-ziplist-size -2
list-compress-depth 0

set-max-intset-entries 512

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# 內存淘汰策略
maxmemory-policy allkeys-lru

# 啟用內存壓縮
rdbcompression yes

網絡優化：

# TCP相關優化
tcp-keepalive 300
tcp-backlog 511

# 客戶端超時
timeout 0

# 輸出緩沖區限制
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

8. 故障處理和高可用

8.1 故障檢測機制

8.2 數據一致性保證

主從復制機制：

// Redis主從復制流程
public class RedisReplication {
    
    // 全量同步
    public void fullResync() {
        // 1. 從服務器發送PSYNC命令
        // 2. 主服務器執行BGSAVE生成RDB文件
        // 3. 主服務器將RDB文件發送給從服務器
        // 4. 從服務器載入RDB文件
        // 5. 主服務器將緩沖區的寫命令發送給從服務器
    }
    
    // 增量同步
    public void partialResync() {
        // 1. 從服務器發送PSYNC runid offset
        // 2. 主服務器檢查復制偏移量
        // 3. 如果偏移量在復制積壓緩沖區內，執行增量同步
        // 4. 主服務器將緩沖區中的數據發送給從服務器
    }
}

總結

通過以上深入分析，我們可以看到Redis能夠抗住10萬并發的核心原因包括：

架構層面

單線程模型：避免了線程切換和鎖競爭的開銷
事件驅動：基于epoll的IO多路復用，高效處理大量連接
內存存儲：所有數據存儲在內存中，訪問速度極快

數據結構層面

高效的數據結構：針對不同場景優化的數據結構
內存優化：壓縮列表、整數集合等節省內存的設計
智能編碼：根據數據特點自動選擇最優存儲方式

網絡層面

IO多路復用：單線程處理多個連接
客戶端緩沖區：避免慢客戶端影響整體性能
協議優化：簡單高效的RESP協議

持久化層面

異步持久化：不阻塞主線程的持久化機制
多種策略：RDB和AOF滿足不同場景需求
增量同步：高效的主從復制機制

集群層面

水平擴展：通過分片支持更大規模
高可用：主從復制和故障轉移
負載均衡：智能的數據分布算法

有些小伙伴在工作中可能會問："既然Redis這么強大，是不是可以完全替代數據庫？"答案是否定的。

Redis更適合作為緩存和高速數據存儲，而不是主要的數據存儲。

正確的做法是將Redis與傳統數據庫結合使用，發揮各自的優勢。

最后，要想真正發揮Redis的性能，不僅要了解其原理，更要在實際項目中不斷實踐和優化。

希望這篇文章能夠幫助大家更好地理解和使用Redis。

責任編輯：武曉燕來源：蘇三說技術

Redis 并發場景