一，hash基本情況

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

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

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

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

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

二，hash常用命令詳解

2.1 hset，hget，hexists，hdel

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

2.2 hexists，hdel

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

2.3 hkeys，hvals

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

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

2.4 hgetall，hmget

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

注意：

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

2.5 hlen，hsetnx

hlen是獲取hash中field-value鍵值對的個數(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ì)是針對數(shù)據(jù)進行重新編碼，不同的數(shù)據(jù)有不同的特定，結(jié)合這些特點進行精妙的計算，重新編碼過后，就嫩縮小數(shù)據(jù)的體積：

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

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

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

3.2 hashtable

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

3.3 演示

元素很多時就用hashtable來存 

四，應(yīng)用場景

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

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

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

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

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

最新評論