📚?前言

🌟🌟🌟精彩讀導

本次我們將全面剖析Redis的核心技術要點，包括其豐富的數據類型體系、高效的編碼方式以及秒級響應的性能奧秘。對于渴望深入理解Redis底層機制的技術愛好者，這是一次難得的學習機會！

🔍 推薦擴展閱讀

想了解更多數據庫技術干貨？歡迎訪問小編的CSDN技術博客： 👉GGBondlctrl-CSDN博客 👈 （持續更新分布式系統、中間件等深度技術文章）

💖 讀者互動

您的每一個👍點贊、?收藏和??評論，都是我們持續輸出優質技術內容的強大動力！期待在評論區看到您的見解～

目錄

📚?前言

📚?1.hash類型基礎認識

📚?2.基礎命令

🚀2.1hset & hmset

🚀2.2hget & hmget

🚀2.3hexists

🚀2.4hdel

🚀2.5hkeys

🚀2.6hvals

🚀2.7hgetall

🚀2.8hlen & hstrlen

🚀2.9hsetnx

🚀2.10hincrby & hincrbyfloat

📚?3.hash的編碼方式

🚀3.1ziplist 與hashtable

🚀3.2listpack

📚?4.?hash類型的使用場景

🚀4.1作為緩存

🚀4.2哈希類型和關系型數據庫

---

📚?1.hash類型基礎認識

?如圖下所示：

在Redis的哈希類型數據結構中，數據存儲采用了一種嵌套的鍵值結構，稱為field-value對，這與Redis整體架構中的key-value對需要明確區分。這里的value特指field對應的具體值，而非外層鍵key對應的值。

這種雙層映射結構的具體表現為：

1. 第一層是key-value結構，其中key是哈希表在Redis中的唯一標識符
2. 第二層是field-value結構，存在于每個哈希表內部

field：相當于哈希表中的字段名
value：該字段對應的具體數據值?

📚?2.基礎命令

🚀2.1hset & hmset

hset key field value field2 value2

這里要具體說明一下，其實這兩個關鍵命令是效果是一樣的，沒有什么本質的區別；都可以實現設置一個或者多個鍵值對；

小編的演示如下：

很顯然發現，返回就是成功設置的鍵值對的個數~~~

🚀2.2hget & hmget

hget key field
hmget key field field2 field3

即一次獲取對應key中field鍵的值，或者一次獲取對飲key中多個field的值

演示如下所示：

🚀2.3hexists

判斷hash中是否存在指定的值

hexists key field

即獲取對應key中鍵field對應的值value是否是存在的，若不存在就直接返回0，存在就返回1

注意：這里是不支持多個field的查找的，只能一個一個進行判斷field對應的值是否是存在的；

🚀2.4hdel

del刪除key，hdel刪除field，可以指定多個

hdel key field1 field2 field3

返回的值就是成功刪除的個數；

🚀2.5hkeys

獲取hash中所有的字段，即所有的field（鍵）

hkeys key

遍歷所有的hash，這里的時間復雜度就是O(N)；這里的N隨著表示不同，對應的值也是不一樣的

🚀2.6hvals

獲取hash中所有的value；與hkeys相對

hvals key

上述獲取field或者value，如果此時hash表中內容非常大，那么很有可能會阻塞我們的redis服務器

🚀2.7hgetall

所有的key以及value都會獲取得到

hgetall key

🚀2.8hlen & hstrlen

hlen key
hstrlen key field

獲取hash的長度，即鍵值對的個數，演示如下所示：

第二個命令就是獲取指定field對應的value的長度，單位是字節

🚀2.9hsetnx

hsetnx key field value

不存在就進行設置，若存在則不進行設置，這里和我們字符串中的setnx是差不多一致的；

🚀2.10hincrby & hincrbyfloat

hincrby可以加減整數

hincrbyfloat：可以加減小數

hincrby key field 10

很明顯，這里需要我們的value的值為內部編碼一個整型，而不是字符串類型

好啦，關于hash類型的命令大概就是這些，大家可以按照命令，自己嘗試嘗試~~~

📚?3.hash的編碼方式

🚀3.1ziplist 與hashtable

ziplist即壓縮列表，這里小編之前已經講解過了，這里就是為了節省空間，但是代價就是進行讀寫元素的速度比較慢，如果元素比較少，那么這里的讀取速度影響就是不大的

hashtable表示普通的hash表，可能會浪費一定的空間，例如hash是一個數組，數組上有一些位置上是沒有元素的，但是這里的讀取速度是比較快的

元素個數比較少：ziplist

元素個數比較多：hashtable

注意：每個value的長度都比較短，ziplist，如果某個value的長度太長了，也會轉變化為hashtable

配置項：

hash-max -ziplist-entries配置元素個數（默認512個）

hash-max-ziplist-value來進行配置value的閾長度（默認64字節）

位置：cd /etc/redis下的redis.conf文件中

這里為啥進行編碼判斷的時候，顯示的不是上述兩種呢？？？那就是更新后的內部編碼了

🚀3.2listpack

定位：?? Redis 設計的、ziplist 的??替代者??。

??核心設計：?? 緊湊的連續內存存儲。

最大亮點：?? 解決了 ziplist 的??級聯更新??問題，通過在每個 entry ??末尾??存儲自身長度（backlen）并??倒序編碼??來實現。

• 優點：??
  • 內存占用小、緊湊。
  • 插入/刪除操作??復雜度穩定??（O(1) 或 O(M)，局部影響，無連鎖反應）。
  • 良好的內存局部性（CPU緩存友好）。

??ListPack 成功繼承了 ziplist 的緊湊空間優勢并解決了其級聯更新的問題。Redis 巧妙地利用 ListPack 作為小集合的一種極其節省內存的存儲格式（犧牲了 O(1) 查找以換取空間），并在數據增長時自動切換到 hashtable 以提供 O(1) 查找性能。

???ListPack 的“讀取”：?? ListPack 支持的快速操作是??正向或反向的迭代（遍歷）??，得益于其 backlen 的設計（O(1) 跳到下一個或上一個 entry 的起始位置）。但這種迭代是針對??順序訪問??優化的，??不是針對隨機查找??某個特定元素優化的。

這里說明：listpack是ziplist的優化，但是查找的時間復雜度還是O(N)，不是hashtable與ziplist的結合，這里小編前面一篇文章寫錯了，這里糾正一下

太長的情況下還是：hashtable的編碼方式

📚?4.?hash類型的使用場景

🚀4.1作為緩存

有以下表：

轉化為redis的表示方式：

當然這里string也是可以完成的，但是如果只修改其中一個field，就需要讀出整個json解析為對象后，進行修改之后，再次轉化為json；

使用string類型進行表示：

優點：?操作簡單??存儲效率 (對于整體存取）。 支持原子操作incr，??支持數據過期ttl，靈活性 (存儲格式)（json,自定義二進制...）

缺點：本身的序列化和反序列化需要一定開銷，同時如果總是操作個別屬性則不靈活

而使用hash的方式比較簡單了

hash的表示方式

優點：簡單。直觀，靈活；尤其是在針對信息的局部變更或者獲取操作

缺點：需要控制哈希在ziplist和hashtable兩種內部編碼轉化，可能會造成內存的較大消耗

🚀4.2哈希類型和關系型數據庫

哈希類型是稀疏的，而關系型數據庫就是完全結構化的例如，哈希類型每個鍵都有不同的field，但是，關系型數據庫一旦添加新的列，所有行都要為它設置值，即時為null

關系型數據庫可以做復雜的關系查詢，redis去模擬關系型復雜查詢，會導致維護成本過高，甚至基本不可能

問題：為啥不使用uid作為我們的key，而是重新設置一個key呢？

?

如果不存其實也是可以的；但是，在代碼編寫中，一般都會把uid在value中再存一份，后續在編寫相關代碼來說，使用起來更加方便

🌅🌅🌅~~~~最后希望與諸君共勉，共同進步！！！

---

💪💪💪以上就是本期內容了， 感興趣的話，就關注小編吧。

? ? ?? 😊😊??期待你的關注~~