前言

Redis 並沒有直接使用資料結構來實現鍵值對資料庫， 而是基於這些資料結構建立了一個物件系統， 這個系統包含字串物件、列表物件、雜湊物件、集合物件和有序集合物件這五種型別的物件， 每種物件都用到了至少一種我們前面所介紹的資料結構。

通過這五種不同型別的物件， Redis 可以在執行命令之前， 根據物件的型別來判斷一個物件是否可以執行給定的命令。 使用物件的另一個好處是， 我們可以針對不同的使用場景， 為物件設定多種不同的資料結構實現， 從而優化物件在不同場景下的使用效率。

除此之外， Redis 的物件系統還實現了基於引用計數技術的記憶體回收機制： 當程式不再使用某個物件的時候， 這個物件所佔用的記憶體就會被自動釋放； 另外， Redis 還通過引用計數技術實現了物件共享機制， 這一機制可以在適當的條件下， 通過讓多個數據庫鍵共享同一個物件來節約記憶體。

物件的型別與編碼

Redis 使用物件來表示資料庫中的鍵和值， 每次當我們在 Redis 的資料庫中新建立一個鍵值對時， 我們至少會建立兩個物件， 一個物件用作鍵值對的鍵（鍵物件）， 另一個物件用作鍵值對的值（值物件）。

Redis 中的每個物件都由一個 redisObject 結構表示， 該結構中和儲存資料有關的三個屬性分別是 type 屬性、 encoding 屬性和 ptr 屬性：

 1 typedef struct redisObject {
 2 
 3     // 型別
 4     unsigned type:4;
 5 
 6     // 編碼
 7     unsigned encoding:4;
 8 
 9     // 指向底層實現資料結構的指標
10     void *ptr;
11 
12     // ...
13 
14 } robj;

我們可以看到一個物件中主要包含了三種欄位。

type： 表示物件的型別。比如String，List，Hash等等

encoding：表示物件底層用的是什麼資料結構。如INT(整數)，EMBSTR(簡潔版sds)，RAW(sds)，HT(map)等等

ptr：ptr是一個指標，指向物件所用的資料結構。

如下圖所示： 

set  k v

k是String型別，embstr資料結構，也就是簡潔版的sds，後續講。

embstr與sds區別

之前我們講資料結構，都沒有見到過embStr，是的，我也是看到這一節才知道有這個東西的。

Redis為了優化，搞了一個embStr，他是為了專門存短字串的一種編碼優化方式。

• embstr 編碼將建立字串物件所需的記憶體分配次數從 raw 編碼的兩次降低為一次。raw 編碼會呼叫兩次記憶體分配函式來分別建立 redisObject 結構和 sdshdr 結構， 而 embstr 編碼則通過呼叫一次記憶體分配函式來分配一塊連續的空間， 空間中依次包含 redisObject 和 sdshdr 兩個結構。因為一個連續，一個不連續。

• 釋放 embstr 編碼的字串物件只需要呼叫一次記憶體釋放函式， 而釋放 raw 編碼的字串物件需要呼叫兩次記憶體釋放函式。理由同上

• 因為 embstr 編碼的字串物件的所有資料都儲存在一塊連續的記憶體裡面， 所以這種編碼的字串物件比起 raw 編碼的字串物件能夠更好地利用快取帶來的優勢。

總的來說，因為embstr分配的是一段連續的記憶體，使得它分配釋放記憶體都是一次，所以效率會有所提高。同時embste   <==>  sds  為44個位元組。

從下圖中，我們可以明確看到。 len <= 44 都是embster的資料結構，如果len > 44 則轉變為raw。至於為啥44。

大家可以去算一下。參考文章：

https://zhuanlan.zhihu.com/p/67876900    

https://xiaoyue26.github.io/2019/01/19/2019-01/redis%E7%9A%84embstr%E4%B8%BA%E4%BB%80%E4%B9%88%E6%98%AF39B/

記憶體

Redis為了節省記憶體，真的是操碎了心。

c語言不像Java，Go等語言，本身不具備自動回收記憶體機制。Java的記憶體回收導致STW一直被人詬病，最近看了ZGC的資料，Java真的是崛起了。

因此Redis 在自己的物件系統中構建了一個引用計數（reference counting）技術實現的記憶體回收機制， 通過這一機制， 程式可以通過跟蹤物件的引用計數資訊， 在適當的時候自動釋放物件並進行記憶體回收。

 但熟悉JVM的都知道，引用計數他有一種缺陷就是，解決不了迴圈引用的問題。

如  A   <==>  B  但已經沒有其他任何節點引用AB了，但AB由於相互引用，計數為1，永遠不會被回收。所以Java用了GC ROOT。

但Redis不知道為啥不存在這個問題，找了資料，也沒找出什麼原因。大多都說Redis沒有複雜的結構，所以？有大佬能解答下不？

引用計數我們可以通過  OBJECT refcount token 命令，查詢到token被引用了幾次，如果為0，那麼則可以回收了。

還有最重要的一點是，Redis對整數 0-9999(共1W個整數)做了快取。類似於Java對-128-127做快取一樣。

但是沒有對值的字串，如aaaaa的這種快取，畢竟判斷一個字串是否在庫裡面，需要掃整個庫，非常耗時，並且cpu壓力非常的大。

處於優化，折中的考慮，也就快取了0-9999吧。其實看看淘寶商品的價格，快取0-100足矣，畢竟0-100佔據了99%的商品。

具體可看：http://redisbook.com/preview/object/share_object.html

後言

• Redis 資料庫中的每個鍵值對的鍵和值都是一個物件。

• Redis 共有字串、列表、雜湊、集合、有序集合五種型別的物件， 每種型別的物件至少都有兩種或以上的編碼方式， 不同的編碼可以在不同的使用場景上優化物件的使用效率。

• 伺服器在執行某些命令之前， 會先檢查給定鍵的型別能否執行指定的命令， 而檢查一個鍵的型別就是檢查鍵的值物件的型別。

• Redis 的物件系統帶有引用計數實現的記憶體回收機制， 當一個物件不再被使用時， 該物件所佔用的記憶體就會被自動釋放。

• Redis 會共享值為 0 到 9999 的整數物件。

• 物件會記錄自己的最後一次被訪問的時間， 這個時間可以用於計算物件的空轉時間。

參考： 

• Redis（八）理解記憶體
• 物件

&n