主頁 > 知識庫 > redis的hGetAll函數(shù)的性能問題(記Redis那坑人的HGETALL)

redis的hGetAll函數(shù)的性能問題(記Redis那坑人的HGETALL)

熱門標簽:太原營銷外呼系統(tǒng) 地圖標注費用 百度商家地圖標注怎么做 最簡單的百度地圖標注 小紅書怎么地圖標注店 地圖標注如何即時生效 玄武湖地圖標注 西藏教育智能外呼系統(tǒng)價格 竹間科技AI電銷機器人

在沒關(guān)注這個函數(shù)之前,一直用的Memcache的數(shù)據(jù)存儲方式,但是自從更換了redis之后,對于一個hash的數(shù)據(jù)存與取 對于Memcache方便甚多,但是問題來了,一個hash的列表如果量不大的情況,用hGetAll函數(shù)幾乎看不出問題,一旦這個列表超過50或者更多時,此時用hGetAll函數(shù)便能很直觀的看到性能問題,這里就不作數(shù)據(jù)分析了。

Redis是單線程的!當它處理一個請求時其他的請求只能等著。通常請求都會很快處理完,但是當我們使用HGETALL的時候,必須遍歷每個字段來獲取數(shù)據(jù),這期間消耗的CPU資源和字段數(shù)成正比,如果還用了PIPELINING,無疑更是雪上加霜。

復制代碼 代碼如下:

PERFORMANCE = CPUs / OPERATIONs

也就是說,此場景下為了提升性能,要么增加運算過程中的CPU數(shù)量;要么降低運算過程中的操作數(shù)量。在為了繼續(xù)使用hash結(jié)構(gòu)的數(shù)據(jù),又要解決此問題,比較方便的方法就是將hash以序列化字符串存儲,取的時候先取出反序列化的數(shù)據(jù),再用hGet(key,array(hash..))。

例如:

復制代碼 代碼如下:

....
$arrKey = array('dbfba184bef630526a75f2cd073a6098','dbfba184bef630526a75f2cd0dswet98')
$strKey = 'test';
$obj->hGet($strKey,$arrKey);

把原本的hGetAll操作簡化為hGet,也就是說,不再需要遍歷hash中的每一個字段,因此即便不能讓多個CPU參與運算,但是卻大幅降低了操作數(shù)量,所以性能的提升仍然是顯著的;當然劣勢也很明顯,和所有的冗余方式一樣,此方案浪費了大量的內(nèi)存。

有人會問,這樣雖然沒有了遍歷字段的過程,但是卻增加了反序列化的過程,而反序列化的成本往往也是很高的,難道這樣也能提升性能?問題的關(guān)鍵在于開始我們遍歷字段的操作是在一個cpu上完成的,后來反序列化的操作,不管是什么語言,都可以通過多進程或多線程來保證是在多個cpu上完成的,所以性能總體上是提升的。

另外,很多人直覺是通過運行redis多實例來解決問題。確實,這樣可以增加運算過程中的CPU數(shù)量,有助于提升性能,但是需要注意的是,hGetAll和PIPELINING往往會讓運算過程中的操作數(shù)量呈幾何級爆炸式增長,相比之下,我們能增加的redis多實例數(shù)量簡直就是杯水車薪,所以本例中這種方法不能徹底解決問題。

記Redis那坑人的HGETALL

世上本沒有坑,摔的人多了,也便成了坑。

早就聽人說過Redis的HGETALL是個坑,可我偏偏不信邪:不管什么坑,一定要自己踩上去跺兩腳才肯罷休。說好聽點這是不到黃河心不死,說難聽點就是不見棺材不落淚。

開始程序運行的非常穩(wěn)定,穩(wěn)定到我想送所有說HGETALL是個坑的人一個字:呸!此時的我就像溫水里的青蛙一樣忘記了危險的存在,時間就這樣一天一天的過去,突然有一天需求變了,我不得不把HASH數(shù)據(jù)的內(nèi)容從十幾個字段擴展到一百多個字段,同時使用了Pipelining一次性獲取上百個HGETALL的結(jié)果。于是我掉坑里了:服務(wù)器宕機。

為什么會這樣?Redis是單線程的!當它處理一個請求時其他的請求只能等著。通常請求都會很快處理完,但是當我們使用HGETALL的時候,必須遍歷每個字段來獲取數(shù)據(jù),這期間消耗的CPU資源和字段數(shù)成正比,如果還用了PIPELINING,無疑更是雪上加霜。

如何解決這個問題?請容許我煞有其事的給出一個公式:

復制代碼 代碼如下:

PERFORMANCE = CPUs / OPERATIONs

也就是說,此場景下為了提升性能,要么增加運算過程中的CPU數(shù)量;要么降低運算過程中的操作數(shù)量。具體來說,我大致想到了以下幾種方法:

借助Memcached

Redis存儲方式不做任何改變,額外的,我們借助Memcached實現(xiàn)一套緩存,里面存儲原本需要在Redis里HGETALL的HASH,當然,由于Memcached里存儲的都是字符串,所以當我們存儲HASH的時候,實際上存儲的是HASH序列化后的字符串,查詢的時候再反序列化即可,通常Memcached客戶端驅(qū)動可以透明實現(xiàn)序列化和反序列化的過程。此方案的優(yōu)勢在于因為Memcached支持多線程,所以可以讓更多的CPU參與運算,同時由于不用再遍歷每一個字段,所以相應(yīng)的操作會減少;當然劣勢也不少,因為引入了一個新的緩存層,所以浪費了內(nèi)存,增加了復雜性,另外,有時候即便我們只需要獲取少數(shù)幾個字段的數(shù)據(jù),也不得不先查詢完整的數(shù)據(jù),然后再篩選,這無疑浪費了帶寬。當然這種情況下我們可以直接查詢Redis,但是無疑又提升了一些復雜性。

順便說一句,Memcached支持Multiget,可以實現(xiàn)類似Pipelining的效果,但你要格外小心這里面有關(guān)Memcached的坑,也就是Mulitiget無底洞問題。

序列化字段冗余

Redis在存儲HASH的時候,多保存一個名為「all」的字段,其內(nèi)容是原HASH數(shù)據(jù)的序列化,實際查詢的時候,只要HGET這個冗余字段后再反序列化即可。此方案的優(yōu)勢在于通過序列化字段冗余,我們把原本的HGETALL操作簡化為HGET,也就是說,不再需要遍歷HASH中的每一個字段,因此即便不能讓多個CPU參與運算,但是卻大幅降低了操作數(shù)量,所以性能的提升仍然是顯著的;當然劣勢也很明顯,和所有的冗余方式一樣,此方案浪費了大量的內(nèi)存。

有人會問,這樣雖然沒有了遍歷字段的過程,但是卻增加了反序列化的過程,而反序列化的成本往往也是很高的,難道這樣也能提升性能?問題的關(guān)鍵在于開始我們遍歷字段的操作是在一個CPU上完成的,后來反序列化的操作,不管是什么語言,都可以通過多進程或多線程來保證是在多個CPU上完成的,所以性能總體上是提升的。

另外,很多人直覺是通過運行Redis多實例來解決問題。確實,這樣可以增加運算過程中的CPU數(shù)量,有助于提升性能,但是需要注意的是,HGETALL和PIPELINING往往會讓運算過程中的操作數(shù)量呈幾何級爆炸式增長,相比之下,我們能增加的Redis多實例數(shù)量簡直就是杯水車薪,所以本例中這種方法不能徹底解決問題。

坑,就是用來踩的。不用怕掉進去,當然前提是你能自己爬出來!

您可能感興趣的文章:
  • Python使用Redis實現(xiàn)作業(yè)調(diào)度系統(tǒng)(超簡單)
  • PHP的Laravel框架結(jié)合MySQL與Redis數(shù)據(jù)庫的使用部署
  • php基于redis處理session的方法
  • Linux下Redis的安裝和部署
  • Java連接Vmware中的redis
  • Nginx配置srcache_nginx模塊搭配Redis建立緩存系統(tǒng)
  • 在CenOS系統(tǒng)下安裝和配置Redis數(shù)據(jù)庫的教程
  • C++訪問Redis的mset 二進制數(shù)據(jù)接口封裝方案
  • C++開發(fā)的Redis數(shù)據(jù)導入工具優(yōu)化
  • 淺談Redis在分布式系統(tǒng)中的協(xié)調(diào)性運用

標簽:唐山 廣東 澳門 贛州 景德鎮(zhèn) 香港 揚州 林芝

巨人網(wǎng)絡(luò)通訊聲明:本文標題《redis的hGetAll函數(shù)的性能問題(記Redis那坑人的HGETALL)》,本文關(guān)鍵詞  redis,的,hGetAll,函數(shù),性能,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《redis的hGetAll函數(shù)的性能問題(記Redis那坑人的HGETALL)》相關(guān)的同類信息!
  • 本頁收集關(guān)于redis的hGetAll函數(shù)的性能問題(記Redis那坑人的HGETALL)的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章