Redis使用SDS而不是C語言字符串的原因！
前言
朋友們，我是小許，今天我們聊一聊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)) 的作用就是告訴編譯器取消結構在編譯過程中的優化對齊,按照實際占用字節數進行對齊。
Redis SDS默認情況下是按sdshdr8（8字節來分配），而經過__attribute__ ((packed)) 定義結構體，目的就是讓編譯器按照實際占用來分配內存空間。
