Redis使用SDS而不是C語言字符串的原因！

作者：小許code 2024-02-20 20:12:09

Redis SDS默認情況下是按sdshdr8（8字節來分配），而經過__attribute__ ((packed)) 定義結構體，目的就是讓編譯器按照實際占用來分配內存空間。

前言

朋友們，我是小許，今天我們聊一聊Redis Sting類型！

Redis為開發者提供了豐富的數據類型，而String類型使用的比較廣泛一種，使用也比較簡便。

你看用下面命令就可以設置和獲取Redis字符串值：

redis 127.0.0.1:6379> SET xiaoxu code
OK
redis 127.0.0.1:6379> GET xiaoxu
"code"

Redis 是用 C 語言寫的，但是對于Redis的字符串，卻不是 C 語言中的字符串（即以空字符’\0’結尾的字符數組），它是自己構建了一種名為簡單動態字符串（simple dynamic string）簡稱SDS的抽象類型，并將 SDS 作為 Redis的默認字符串表示。

圖片

今天的主要內容就來說說Redis 什么使用SDS，然后了解String數據類型底層數據結構、原理和一些注意事項！

Redis 字符串

SDS名為簡單動態字符串，它是內部如何設計的，既然是C語言寫的為什么不用C語言的字符串呢？

帶著這些問題我們繼續往下看！

二進制安全性

??♂? 什么是二進制安全性？

二進制安全是指一種數據處理或傳輸的方式，其中對待數據的處理不會受到數據中包含的二進制數據的影響。在計算機科學和編程中，這個術語通常與字符串的處理有關。

?? C語言字符串和Redis SDS的二進制安全性問題對比

C 語言中字符串是以遇到的第一個空字符 \0 來識別是否到末尾，因此其只能保存文本數據，不能保存圖片，音頻，視頻和壓縮文件等二進制數據，否則可能出現字符串不完整的問題，所以其是二進制不安全。

Redis SDS（簡單動態字符串）允許不受限制地存儲和操作任意長度的二進制數據，保證了二進制安全。

C語言字符串的不足

上面我們通過C語言字符串和Redis SDS二進制安全性問題的現象對比，我們知道了C語言字符串只能保存文本數據，不能保存圖片，音頻，視頻和壓縮文件等二進制數據。

與Redis的SDS比起來有以下不足：

? 獲取字符串長度的時間復雜度為 n
? API是不安全的可能造成緩沖區溢出
? 只能保存文本數據

SDS結構

現在開始進入正題，挖一挖Redis String的底層實現！

我們復制了其中一種SDS類型【sdshdr8】，它在Redis源碼中的結構代碼如下：

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; 
    uint8_t alloc; 
    unsigned char flags; 
    char buf[]; 
};

字段說明：

? len : 記錄buf數組中已使用的字節數量
? alloc : 分配的buf數組長度，不包括頭和空字符結尾
? flags : 標志位，標記當前字節數組是 sdshdr8/16/32/64 中的哪一種，占 1 個字節。
? buf[] : 字符數組，用于存放實際字符串

圖片

定義的這些字段有以下一些好處：

? 用單獨的變量 len 和 free，可以方便地獲取字符串長度和剩余空間；
? 內容存儲在動態數組 buf 中，SDS 對上層暴露的指針指向 buf，而不是指向結構體 SDS。因此，上層可以像讀取 C 字符串一樣讀取 SDS 的內容，兼容 C 語言處理字符串的各種函數，同時也能通過 buf 地址的偏移，方便地獲取其他變量；
? 讀寫字符串不依賴于 \0，保證二進制安全。

對應在文章開頭中我們設置的 key="xiaoxu"、value="code"，存儲情況如下圖所示：

圖片

從圖中可以看出SDS 也遵循 C 字符串以空字符“\0”結尾的慣例，而保存空字符的大小不計算在 SDS 的 len 屬性中。

不過你也注意到了此時表示SDS類型的flags字段的值是 1，也就是 sdshdr8。

SDS類型

在SDS結構一節中我們使用的是sdshdr8，而Redis 3.2 版本之后，SDS 由一種數據結構變成了 5 種數據結構。

??這5 種類型分別是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64

五種類型的區別在于數組的 len 長度和分配空間長度 alloc。

圖片

? sdshdr5：存儲大小為 32 byte = 2^ 5 【被棄用】

? sdshdr8：存儲大小為 256 byte = 2^ 8

? sdshdr16：存儲大小為 64KB = 2 ^16

? sdshdr32：存儲大小為 4GB = 2^ 32

? sdshdr64：存儲大小為 2^ 64

圖片

上面5 種數據結構存儲不同長度的內容，而在使用中Redis 會根據 SDS 存儲的內容長度來選擇不同的結構。

底層編碼選擇

字符串是 Redis最基本的數據類型，Redis 中字符串對象的編碼可以是下面三種類型：

圖片

? int 編碼：存儲8個字節的長整型（long，2^63-1）字符串，長度小于等于20

? embstr 編碼：長度小于44字節的字符串

? raw 編碼：長度大于44字節的字符串

講了半天理論還比不上一個案例，這里舉個栗子：

以下案例截取自網絡

圖片

從圖中我們可以可以發現，當輸入純數字字符串的時候，采用的是 int 編碼，而字符串小于等于 44 則為 embstr，大于 44 則為 raw 編碼

注：編碼轉換在Redis寫入數據時完成，且轉換過程不可逆，只能從小內存編碼向大內存編碼轉換

?? embstr和raw之間有什么區別？

embstr：只分配一次內存空間，SDS結構體和RedisObject分配在同一塊連續的內存空間
raw：需要分配兩次內存空間，SDS結構體和依賴RedisObject不在連續

圖片

SDS相對C字符串的好處

SDS 是Redis中用于存儲二進制數據的一種結構, 具有動態擴容的特點。

使用它主要有以下好處：

? 讀取字符串長度快：獲取 SDS 字符串的長度只需要讀取 len 屬性，時間復雜度為 O(1)

? 杜絕緩沖區溢出：SDS 數據類型，在進行字符修改的時候，會首先根據記錄的 len 屬性檢查內存空間是否滿足需求

? 二進制安全：SDS 的API 都是以處理二進制的方式來處理 buf 里面的元素，并且 SDS 不是以空字符串來判斷是否結束

? 減少內存重新分配次數：對于修改字符串SDS實現了空間預分配和惰性空間釋放兩種策略

這些好處也就解釋了為什么Redis要使用SDS來實現字符串了。

文末提問

1：SDS實際能存儲多大字符串？

SDS 結構中 alloc字段表示允許容納的最大字符長度，而類型為sdshdr32的存儲大小為 4GB，但是現實并不是這樣的。

Redis的文檔和源代碼中寫死它的字符串最大長度為512M，超過這個長度將報錯

static int checkStringLength(client *c, long long size) {
    if (size > 512*1024*1024) {
        addReplyError(c,"string exceeds maximum allowed size (512MB)");
        return C_ERR;
    }
    return C_OK;
}

那為什么在Redis中會設置這個限制呢？我覺得可能還有如下考慮

? 程序中一般不會有那么大的數據量存入緩存
? 大的數據量對網絡和性能有一定影響

2：SDS如何空間預分配和惰性空間釋放？

Redis的SDS，由于len屬性和alloc屬性的存在，對于修改字符串SDS實現了空間預分配和惰性空間釋放兩種策略：****

? 空間預分配：對字符串進行空間擴展的時候，擴展的內存比實際需要的多，這樣就不需要每次增大字符串都需要分配空間，減少了內存重分配的次數

? 惰性空間釋放：對字符串進行縮短操作時，程序空余出來的空間并不會直接釋放，而是會被保留，等待下次再次使用

3：attribute ((packed))是什么？

在Redis SDS定義的五種結構體類型中有一個 attribute ((packed)) 關鍵字聲明

圖片

attribute ((packed)) 的作用就是告訴編譯器取消結構在編譯過程中的優化對齊,按照實際占用字節數進行對齊。