Redis沒有直接使用C語言傳統的字符串表示(以空字符結尾的字符數組，以下簡稱C字符串)，而是自己構建了一種名爲簡單動態字符串(simple dynamic string,SDS)的抽象類型，並將SDS用作Redis的默認字符串表示。Reids自己構建的sds要比默認的c字符串性能更好，也更安全。
SDS
那麼sds的結構是什麼樣的呢？與C字符串有什麼不同？
下面是sds的定義
struct sdshdr {
//記錄buf數組中已使用字節的數量
//等於sds所保存字符串的長度
int len;
//記錄buf數組中未使用字節的數量
int free;
//字節數組，用於保存字符串
char buf[];
}
在64位系統下，屬性len和屬性free各佔4個字節，緊接着存放字節數組。
上面的buf[]是一個柔性數組。柔性數組成員(flexible array member)，也叫伸縮性數組成員，只能被放在結構體的末尾。包含柔性數組成員的結構體，通過malloc函數爲柔性數組動態分配內存。
關於柔性數組，可以看這篇文章：C語言柔性數組講解
下面展示一個SDS示例：
set name "Redis"
- free屬性的值爲0，表示這個SDS沒有分配任何未使用空間。
- len屬性的值爲5，表示這個SDS保存了一個物字節長的字符串。
- buf屬性是一個char類型的數組，數組的前五個字節分別保存了'R'、'e'、'd'、'i'、's'五個字符，而最後一個字節則保存了空字符'\0'。
SDS遵循C字符串以空字符結尾的慣例，保存空字符的1字節空間不計算在SDS的len屬性裏面，並且爲空字符分配額外的1字節空間，以及添加空字符到字符串末尾等操作，都是由SDS函數自動完成的，所以這個空字符對於SDS的使用者來說是完全透明的。遵循空字符串結尾這一慣例的好處是，SDS可以直接重用一部分C字符串函數庫裏面的函數。
SDS與C字符串的區別
C語言使用長度爲N+1的字符數組來表示長度爲N的字符串，並且字符數組的最後一個元素總是空字符'\0'。但是C語言使用的這種簡單的字符串表示方式，並不能滿足Redis對字符串在安全性、效率以及功能方面的要求，下面來聊聊爲什麼SDS比C字符串更適合用於Redis。
SDS獲取字符串長度複雜度爲O(1),C字符串爲O(N)
由於C字符串並不記錄自身的長度信息，所以爲了獲取一個C字符串的長度，程序必須遍歷整個字符串，對遇到的每個字符進行計數，直到遇到代表字符串結尾的空字符爲止，這個操作的複雜度爲O(N)。
和C字符串不，因爲SDS在len屬性中記錄了SDS本身的長度，所以獲取一個SDS長度的複雜度爲O(1)。
通過使用SDS而不是C字符串，Redis將獲取字符串長度所需的複雜度從O(N)降低到了O(1)，這確保了獲取字符串長度的工作不會成爲Redis的性能瓶頸。所以，即使我們對一個非常長的字符串反覆執行STRLEN命令，也不會對系統性能造成任何影響，因爲STRLEN命令的複雜度僅爲O(1)。
SDS杜絕了緩存區溢出
C字符串不記錄自身長度除了會導致獲取字符串長度複雜度高之外，還帶來的另一個問題就是容易造成緩存區溢出(buffer overflow)。舉個例子，假設程序裏有兩個在內存中緊鄰着的C字符串s1和s2，其中s1保存了字符串"Redis"，而s2則保存了字符串"MongoDB"，如下圖所示。
如果一個程序員決定通過strcat(s1, " Cluster")將s1的內容修改爲"Redis Cluster"，但粗心的他卻忘了在執行strcat之前爲s1分配足夠的空間，那麼在strcat函數執行之後，s1的數據將溢出到s2所在的空間中，導致s2保存的內容被意外地修改，如下圖所示。
這是使用C字符串所會帶來的問題。與C字符串不同，SDS的空間分配策略完全杜絕了發生緩存區溢出的可能性：當SDS API需要對SDS進行修改時，API會先檢查SDS的空間是否滿足修改所需的要求，如果不滿足的話，API會自動將SDS的空間擴展至修改所需的大小，然後才執行實際的修改操作，所以使用SDS既不需要手動修改SDS的空間大小，也不會出現前面所說的緩存區溢出問題。
減少修改字符串時帶來的內存重分配次數
因爲C字符串並不記錄自身的長度，所以對於一個包含了N個字符的C字符串來說，這個C字符串的底層實現總是一個N+1個字符長的數組(額外的一個字符空間用於保存空字符)。因爲C字符串的長度和底層數組的長度之間存在着這種關聯性，所以每次增長或者縮短一個C字符串，程序都總要對保存這個C字符串的數組進行一次內存重分配操作：
- 如果程序執行的是增長字符串的操作，比如拼接操作(append)，那麼在執行這個操作之前，程序需要先通過內存重分配來擴展底層數組的空間大小--如果忘了這一步就會產生緩存區溢出。
- 如果程序執行的是縮短字符串的操作，比如截斷操作(trim)，那麼在執行這個操作之後，程序需要通過內存重分配來釋放字符串不再使用的那部分空間--如果忘了這一步就會產生內存泄漏。
爲了避免C字符串的這種缺陷，SDS通過未使用空間解除了字符串長度和底層數組長度之間的關聯：在SDS中，buf數組的長度就不一定是字符數量加一，數組裏面可以包含未使用的字節，而這些字節的數量就由SDS的free屬性記錄。
通過未使用空間，SDS實現了空間預分配和惰性空間釋放兩種優化策略。
1.空間預分配
空間預分配用於優化SDS字符串增長操作：當SDS的API對一個SDS進行修改，並且需要對SDS進行空間擴展的時候，程序不僅會爲SDS分配修改所必須要的空間，還會爲SDS分配額外的未使用空間。其中額外分配的未使用空間數量由以下公司決定：
- 如果對SDS進行修改之後，SDS的長度(也即len屬性的值)小於1MB，那麼程序分配和len屬性同樣大小的未使用空間，這時SDS len屬性的值將和free屬性的值相同。舉個例子，如果進行修改之後，SDS的len將變成13字節，那麼程序也會分配13字節的未使用空間，SDS的buf數組的實際長度將變成13+13+1字節(額外的一字節用於保存空字符)。
- 如果對SDS進行修改之後，SDS的長度將大於等於1MB，那麼程序會分配1MB的未使用空間。舉個例子，如果進行修改之後，SDS的len變成了30MB，那麼程序會分配1MB的未使用空間，SDS的buf數組的實際長度爲30MB+1MB+1byte。
通過空間預分配策略，Redis可以減少連續執行字符串增長操作所需的內存重分配次數。
2.惰性空間釋放
惰性空間釋放用於優化SDS的字符串縮短操作：當SDS的API需要縮短SDS保存的字符串是，程序並不立即使用內存重分配來回收縮短後多出來的字節，而是使用free屬性來將這些字節的數量記錄起來，並等待將來使用。
通過惰性空間釋放策略，SDS避免了縮短字符串時所需的內存重分配操作，並未將來可能有的增長操作提供了優化。與此同時，ADS也提供了相應的API，讓我們可以在有需要時，真正地釋放SDS的未使用空間，所以不用擔心惰性空間釋放策略會造成內存浪費。
二進制安全
什麼是二進制安全？
通俗地將，C語言中，用'\0'表示字符串的結束，如果字符串本身就有'\0'字符，字符串就會被截斷，既非二進制安全；若通過某種機制，保證讀寫字符串時不損害其內容，則是二進制安全。
C字符串中的字符必須符合某種編碼(比如ASCII),並且除了字符串的末尾之外，字符串裏面不能包含空字符，否則最先被程序讀入的空字符將被誤認爲是字符串結尾，這些限制使得C字符串只能保存文本數據，而不能保存像圖片、音頻、視頻、壓縮文件這樣的二進制數據。
爲了確保Redis可以適用於各種不同的使用場景(保存文本、圖像、音視頻等)，SDS的API都是二進制安全的(binary-safe)，所有SDS API都會以處理二進制的方式來處理SDS存放在buf數組裏的數據，程序不會對其中的數據做任何限制、過濾、或者假設，數據在寫入時是神峨眉樣的，它被讀取時就是什麼樣的。
這也是將SDS的buf屬性成爲字節數組的原因----Redis不是用這個數組來保存字符，而是用它來保存一系列二進制數據。
整理自：
《redis設計與實現(第二版)》
《redis5設計與源碼分析》