一.引言

Redis 實際使用過程中，由于?redis hgetAll 數據量過于大，導致線上 redis 進程堵塞，讀取緩慢影響任務執行效率，改用 hscan 優化。

二.Case分析

1.hgetAll 為什么慢

hgetAll 獲取指定 key 的全部 hash 結果，時間復雜度 O(n) ，hash 的 key 越多，當 kv 值不多時 hgetAll 非常好用，但是使用 hgetAll 獲取的數據量越大，獲取的性能越低。與之類似的是 hdel，隨著 key 的增加，獲取的時間并不是完全的線性增加，而是可能出現翻倍的情況。因此對于高并發的場景，要盡量避免在大數據上進行 hgetAll，hdel，emembers 等操作。

2.hscan 怎么代替

scan，hscan 是增量式迭代命令，通過游標進行分段式讀取，負載壓力從而不會堵塞 redis 線程，但是速度會慢于 hgetall。hscan 主要用到 ScanParams，通過 ScanParams.count() 方法可以設置每次迭代獲取的數據量，假設hgetAll redis read峰值很高，正常值 200，那就可以設定 count(200)。還有一個參數是 SCAN_POINTER_START，該字符型變量標記當前獲取的游標，當游標為"0"時，代表全部元素獲取完畢。

Tips:

hscan 每次返回的結果可能存在重復，最后整合所有結果時需要自己去重

3.還有方法減小壓力嘛

A.redis.dump

redis.dump(key) 可以獲取對應元素序列化后的內容 Array[Byte]，可以使用 redis 相同的序列化協議進行反序列化，從而避免在 redis 客戶端執行序列化，縮短時間

B.拆分 key-value

將原始 HashMap 分布在多個 key 上，縮小每個 Hmap 的大小，整體的數據量變化不大

C.加機器

和拆分的思想類似，可以提高 redis 數量，通過 redis-pool 減輕單點 redis 的壓力

D.數據量很大

轉存 Hbase

三.hscan 實現代碼

A.ScanParams 初始化每次迭代的數量，count 為迭代量

B.SCAN_POINTER_START 為計數游標，標記為"0"時代表全部迭代結束

C.scanResult.getResult() 返回 util.Map.Entry 接口，此接口為泛型，定義為Entry<K,V>，轉換后存入 map 即可

def redisHScan(jedis: Jedis, key: String, count: Int = 100): mutable.HashMap[String, String] = {val infoMap = mutable.HashMap[String, String]()val scanParams = new ScanParams().count(count)var cur = redis.clients.jedis.ScanParams.SCAN_POINTER_STARTvar cycleIsFinished = falsewhile (!cycleIsFinished) {val scanResult = jedis.hscan(key, cur, scanParams)val result = scanResult.getResult.asScala.map(entry => (entry.getKey, entry.getValue))infoMap ++= resultcur = scanResult.getStringCursorif (cur == "0") cycleIsFinished = true}infoMap}val scanMap = redisHScan(redis, key, 100000)

下面對一個 55w+ key 的 HashMap 進行讀取測試:

????

四.總結

hgetAll 獲取大 key 時可以用 hscan 替代，但也需要注意 count 的大小和 Redis 具體的壓力，除此之外還有一點需要注意，由于 hscan 是迭代獲取執行，所以可能存在數據不一致的情況，獲取靠前的數據時，靠后的數據已被修改，這時候會出現先到的數據為老數據，后到的數據為新數據的情況。

總結

以上是生活随笔為你收集整理的Scala - Redis hgetAll 优化 by hscan的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。