redis整數(shù)集不能降級的原因是什么

這篇文章主要為大家展示了“redis整數(shù)集不能降級的原因是什么”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學習一下“redis整數(shù)集不能降級的原因是什么”這篇文章吧。

頭屯河ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

基本結(jié)構(gòu)

在src/t_set.c中我們發(fā)現(xiàn)這樣一段代碼

由此我們可知在set中是由兩種數(shù)據(jù)結(jié)構(gòu)構(gòu)成的： hashtable+intset 。關(guān)于redis內(nèi)部其他的結(jié)構(gòu)我專門在【redis專欄中有介紹】。hashtable不是我們今天的主角，我們今天先分析intset俗稱整數(shù)集合。

從上圖中我們可以看出，我構(gòu)造了兩個set集合分別為【commonset】、【cs】。兩個集合前者存儲字符串、后者專門存儲數(shù)字。

我們在通過object encoding key 來查看下兩個集合的底層數(shù)據(jù)結(jié)構(gòu)，發(fā)現(xiàn)一個是hashtable 一個是intset  。這也驗證了我們上面對set基本結(jié)構(gòu)的描述。

在redis中對外提供五大類型實際上都是redis的一個抽象對象叫做redisobject。在內(nèi)部映射了我們redis內(nèi)部的數(shù)據(jù)結(jié)構(gòu)

針對commonset和cs兩個集合在內(nèi)部數(shù)據(jù)結(jié)構(gòu)大概可以這么理解

何時使用intset

你可以單純的認為只要是數(shù)字就會使用intset結(jié)構(gòu)來存儲，我恐怕要給你當頭一棒了。實際上并不是這樣

需要同時滿足以下兩個條件：

intset

圖中表示的很清楚了，在intset中的encoding有三種取值分別代表contents保存數(shù)據(jù)類型。這里有人可能會有疑問了contents的類型不就是int8_t嗎？為什么還需要encoding呢？這里通過源碼跟蹤內(nèi)部的確跟int8_t沒啥關(guān)系。而且數(shù)據(jù)的默認類型就是int16_t 。關(guān)于length這里無需太多解釋，記住一點表示contents元素的個數(shù)并非表示contents數(shù)組的長度！

了解intset的同學都知道在encoding三種取值范圍中涉及了升級的操作！在講升級之前我們先來了解下C、C++中int的取值范圍是如何定義的

int8_t的取值范圍是【-128,127】 。 類似于java中byte占1個字節(jié)也就是8位。他的取值范圍是

\[-2^{7} \sim 2^{7}-1   \\即 \\ -128 \sim 127 \]

添加元素

sadd juejin -123
sadd juejin -6
sadd juejin 12
sadd juejin 56
sadd juejin 321

juejin這個key內(nèi)部就是intset 。

上面我們添加了5個元素且這五個元素的長度都在16之內(nèi)！所以當前的intset的encoding=INTSET_ENC_INT16。-123在contents中占前16位。

所以當前五個元素占contents的長度是16*5=80 ；

注意set在存儲int類型數(shù)據(jù)時，內(nèi)部是按照從小到大的順序存儲的。

類型變動

上面的問題不知道你有沒有考慮過，或者說有沒有遇到過！intset默認是int16位，正如我們上面添加的五個元素。加入此時我們添加第6個元素是65535(32位)。那么此時16位的長度就不夠存儲了這個時候intset會怎么做！

另外當我們添加第6個元素后又將65535刪除了之后，結(jié)構(gòu)和添加之前是否一樣！下面我們帶著這兩個問題來一探究竟?。。?/p>

升級

首先我們針對第一問題來看看。原來五個元素都是16位就可以滿足了，這個時候添加的65535是32位長度的。那么是不是可以直接追加32位分配給65535呢？

答案是肯定不行，首先直接追加無法保證數(shù)組元素的大小順序！其次如果前五個分別是16位，第6個是32位那么在intset結(jié)構(gòu)中沒有多余的字段來進行標記。也就是說在解析的時候就無法判斷應該解析16位還是32位了.

redis為了方便解析所以在有高長度加入時會將整個contents進行升級。意思就是將整個contents先進行擴容，然后在重新填充數(shù)據(jù)

加入65535

首先根據(jù)length可以確定擴容后元素個數(shù)為6 ， 每個占位32，所以contents長度為32*6=192 。 此時前80位內(nèi)容保持不變

舊數(shù)據(jù)移位

開辟了足夠的空間后，我們就可以對舊數(shù)據(jù)進行移位了這里我們從原數(shù)組的末尾開始移動，在移動之前需要明確在新數(shù)組中的排序位置。

此時我們首先將321進行比對確定在新數(shù)組中他的排名是第五名，那么他將占用新contents中128~159區(qū)間。

最終前5 個元素就會被移動好 。

最后將新加入的元素填充進去。當發(fā)生升級時肯定是因為新元素的長度大于原有長度了。那么他的值一定會是在新數(shù)組的兩端。負數(shù)在最左側(cè)，正數(shù)在最右側(cè)

降級

接下來就是第二個問題當新加入的65535又被刪除了redis該怎么辦，這個時候元素長度實際16位就可以滿足了，但是此時encoding卻是32位的。按照我的看法應該在實現(xiàn)降級！

但是遺憾的是redis并沒有，那么請思考為什么沒有？如果讓你實現(xiàn)你將如何實現(xiàn)

為什么不實現(xiàn)降級

當加入元素超過當前長度我們很容易就知道此時需要進行升級操作，但是當我們刪除一個數(shù)據(jù)時我們?nèi)绾闻袛嗍欠裥枰导墔s很困難，我們需要重新遍歷一遍剩下的元素是否小于當前長度，實現(xiàn)復雜度O(N) 。這就是為什么不進行降級原因之一

你可能會說重新遍歷一遍很快的反正在內(nèi)存中，那么你有沒有想過如果降級之后又遇到升級情況，這樣來回的升級降級就降低了我們程序的性能了。我們知道升級是必須的所以這里降級redis采取的是忽略的策略

小結(jié)

以上是“redis整數(shù)集不能降級的原因是什么”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

名稱欄目：redis整數(shù)集不能降級的原因是什么
文章URL：http://bm7419.com/article46/pscjeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、ChatGPT、軟件開發(fā)、服務(wù)器托管、搜索引擎優(yōu)化、網(wǎng)站維護

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)