深入理解Redis之簡單動態字串

玻璃窗起霧了發表於2021-01-19
Redis字串

目錄

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"，如下圖所示。

在記憶體中緊鄰的兩個C字串

如果一個程式設計師決定通過strcat(s1, " Cluster")將s1的內容修改為"Redis Cluster"，但粗心的他卻忘了在執行strcat之前為s1分配足夠的空間，那麼在strcat函式執行之後，s1的資料將溢位到s2所在的空間中，導致s2儲存的內容被意外地修改，如下圖所示。

s1的內容溢位到了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設計與原始碼分析》

相關文章