redis系列之------對象

前言

Redis 並無直接使用數據結構來實現鍵值對數據庫, 而是基於這些數據結構建立了一個對象系統, 這個系統包含字符串對象、列表對象、哈希對象、集合對象和有序集合對象這五種類型的對象, 每種對象都用到了至少一種咱們前面所介紹的數據結構。html

經過這五種不一樣類型的對象, Redis 能夠在執行命令以前, 根據對象的類型來判斷一個對象是否能夠執行給定的命令。 使用對象的另外一個好處是, 咱們能夠針對不一樣的使用場景, 爲對象設置多種不一樣的數據結構實現, 從而優化對象在不一樣場景下的使用效率。git

除此以外, Redis 的對象系統還實現了基於引用計數技術的內存回收機制: 當程序再也不使用某個對象的時候, 這個對象所佔用的內存就會被自動釋放; 另外, Redis 還經過引用計數技術實現了對象共享機制, 這一機制能夠在適當的條件下, 經過讓多個數據庫鍵共享同一個對象來節約內存。github

 

對象的類型與編碼

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是一個指針,指向對象所用的數據結構。函數

以下圖所示: post

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 的整數對象。
  • 對象會記錄本身的最後一次被訪問的時間, 這個時間能夠用於計算對象的空轉時間。

 

參考: 

相關文章
相關標籤/搜索