一，hash基本情況

哈希是我們目前接觸到的數(shù)據(jù)結(jié)構(gòu)中最重要的一個(gè)：

日常開發(fā)中，出場(chǎng)頻率非常高面試中，非常重要的考點(diǎn)

 Redis自身已經(jīng)是鍵值對(duì)結(jié)構(gòu)了，就是通過哈希的方式來組織的，而hash類型，就是把key這一層組織完之后，到了value這一層，其中的一種類型還可以再是一個(gè)哈希表：

哈希類型中的映射關(guān)系通常稱為 field-value，?于區(qū)分 Redis 整體的鍵值對(duì)（key-value）， 注意這?的 value 是指 field 對(duì)應(yīng)的值，不是鍵（key）對(duì)應(yīng)的值，請(qǐng)注意 value 在不同上下文的作用。

關(guān)于哈希的詳細(xì)解釋以前已經(jīng)介紹過，傳送門：C++&&數(shù)據(jù)結(jié)構(gòu)——哈希表_c++哈希表

二，hash常用命令詳解

2.1 hset，hget，hexists，hdel

hset就是同時(shí)建立key-value和field-value鍵值對(duì)，前者是Redis的鍵值對(duì)，后者是value的鍵值對(duì)；hget就是查詢鍵值對(duì)：

2.2 hexists，hdel

hexists的作用是判斷指定key的field是否存在，存在就返回1，否則返回0；hdel就是刪除，刪除key的某一個(gè)field-value，當(dāng)key的field數(shù)量為0時(shí)，會(huì)順帶把key一起刪了：

2.3 hkeys，hvals

hkeys作用是根據(jù)key找到所有的field并打印出來；hvals作用是獲取所有的field和value，但不會(huì)顯示field：

當(dāng)然，像這樣的“查詢所有”的這種操作，也會(huì)有和keys *一樣的問題的，但是也有解決方法，就是hscan遍歷Redis的hash類型，屬于“漸進(jìn)式遍歷”，我們后面再講~ 

2.4 hgetall，hmget

hgetall相當(dāng)于把上面兩個(gè)命令合起來，同時(shí)顯示field和value，以兩兩交替的方式打印出來；hgetall是一次查所有，但是我們有時(shí)只要查一部分，所以可以用hmget，就是根據(jù)命令行輸入field獲取對(duì)應(yīng)value，可以一次查多個(gè)：

注意：

hgetall同樣有keys * 的問題hmget的顯示順序和我們命令行輸入的field的順序是一致的也有hmset一次設(shè)置多個(gè)field和value，但是不用，因?yàn)閔set已經(jīng)可以支持一次設(shè)置多個(gè)field和value了

2.5 hlen，hsetnx

hlen是獲取hash中field-value鍵值對(duì)的個(gè)數(shù)；hsetnx和前面的setnx一樣，如果field不存在就創(chuàng)建，存在就直接返回：

2.6 hincrby，incrbyfloat

hash類型中field的value也可以當(dāng)作int處理，hincrby可以加減整數(shù)，incrbyfloat可以加減小數(shù)：

三，hash編碼方式

3.1 ziplist

我們經(jīng)常用到的壓縮有rar，zip，7z等，通常是一些具體的壓縮算法，本質(zhì)是針對(duì)數(shù)據(jù)進(jìn)行重新編碼，不同的數(shù)據(jù)有不同的特定，結(jié)合這些特點(diǎn)進(jìn)行精妙的計(jì)算，重新編碼過后，就嫩縮小數(shù)據(jù)的體積：

 ziplist同理，內(nèi)部的數(shù)據(jù)結(jié)構(gòu)也是精心設(shè)計(jì)的，表示一個(gè)普通的哈希表，可能會(huì)浪費(fèi)一定的空間（哈希是一個(gè)數(shù)組，數(shù)組上有些位置有元素，有些沒有），使用ziplist就可以節(jié)省空間，內(nèi)部的具體實(shí)現(xiàn)我們以后再看源碼解析

當(dāng)然，有好處自然會(huì)有壞處：讀寫元素較慢，如果元素較少，慢的并不明顯，所以當(dāng)哈希的元素個(gè)數(shù)較少，就會(huì)用ziplist去優(yōu)化

當(dāng)哈希類型元素個(gè)數(shù)?于 hash-max-ziplist-entries 配置（默認(rèn) 512 個(gè)，我們一般會(huì)根據(jù)業(yè)務(wù)修改）、 同時(shí)所有值都?于 hash-max-ziplist-value 配置（默認(rèn) 64 字節(jié)）時(shí)，Redis 會(huì)使? ziplist 作為哈 希的內(nèi)部實(shí)現(xiàn)，ziplist 使?更加緊湊的結(jié)構(gòu)實(shí)現(xiàn)多個(gè)元素的連續(xù)存儲(chǔ)，所以在節(jié)省內(nèi)存??? hashtable 更加優(yōu)秀。

3.2 hashtable

只有“元素個(gè)數(shù)太少”，“長(zhǎng)度比較短”兩個(gè)條件都具備，才會(huì)優(yōu)化成ziplist，當(dāng)hash類型?法滿? 這兩個(gè)條件時(shí)，Redis 會(huì)使? hashtable 作為哈希 的內(nèi)部實(shí)現(xiàn)，因?yàn)榇藭r(shí) ziplist 的讀寫效率會(huì)下降，? hashtable 的讀寫時(shí)間復(fù)雜度為 O(1)。

3.3 演示

元素很多時(shí)就用hashtable來存 

四，應(yīng)用場(chǎng)景

最主要的應(yīng)用場(chǎng)景還是作為緩存來使用，但是hash類型作為緩存有點(diǎn)特別，下面來具體講講

string也是可以用作緩存的，但是Redis是經(jīng)常和MySQL打交道的，所以如果要存儲(chǔ)MySQL表里面那樣的結(jié)構(gòu)化數(shù)據(jù)，使用hash類型更合適一些：

其實(shí)上述場(chǎng)景也可以用strin類型也能做到，需要用到 json 這樣的數(shù)據(jù)格式

• 但是如果使用json的格式來表示上面的user時(shí)，如果我只想獲取或修改其中的一個(gè)field，就需要把整個(gè)json都讀出來，解析成對(duì)象，然后重寫對(duì)應(yīng)的field，再寫回去，效率變低
• 而使用hash，就可以使用field表示對(duì)象的每個(gè)舒徐（相當(dāng)于操作MySQL的每個(gè)列），次數(shù)就可以非常方便地修改任何一個(gè)屬性的值了
• 但是使用hash的方式，確實(shí)讀寫field更直觀和高效，但是付出的是空間的代價(jià)，而且還需要控制hash再ziplist和hashtable兩種內(nèi)部編碼的轉(zhuǎn)換，可能會(huì)造成較大的內(nèi)存消耗

到此這篇關(guān)于Redis遠(yuǎn)程字典服務(wù)器 hash類型詳解的文章就介紹到這了,更多相關(guān)Redis hash類型內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論