記Redis那坑人的HGETALL

2021-08-11 09:04:53 字數 1619 閱讀 6198

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

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

開始程式執行的非常穩定,穩定到我想送所有說hgetall是個坑的人乙個字:呸!此時的我就像溫水裡的青蛙一樣忘記了危險的存在,時間就這樣一天一天的過去,突然有一天需求變了,我不得不把hash資料的內容從十幾個字段擴充套件到一百多個字段,同時使用了pipelining一次性獲取上百個hgetall的結果。於是我掉坑里了:伺服器宕機。

為什麼會這樣?redis是單執行緒的!當它處理乙個請求時其他的請求只能等著。通常請求都會很快處理完,但是當我們使用hgetall的時候,必須遍歷每個欄位來獲取資料,這期間消耗的cpu資源和字段數成正比,如果還用了pipelining,無疑更是雪上加霜。

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

performance = cpus / operations
也就是說,此場景下為了提公升效能,要麼增加運算過程中的cpu數量;要麼降低運算過程中的運算元量。具體來說,我大致想到了以下幾種方法:

redis儲存方式不做任何改變,額外的,我們借助memcached實現一套快取,裡面儲存原本需要在redis裡hgetall的hash,當然,由於memcached裡儲存的都是字串,所以當我們儲存hash的時候,實際上儲存的是hash序列化後的字串,查詢的時候再反序列化即可,通常memcached客戶端驅動可以透明實現序列化和反序列化的過程。此方案的優勢在於因為memcached支援多執行緒,所以可以讓更多的cpu參與運算,同時由於不用再遍歷每乙個字段,所以相應的操作會減少;當然劣勢也不少,因為引入了乙個新的快取層,所以浪費了記憶體,增加了複雜性,另外,有時候即便我們只需要獲取少數幾個欄位的資料,也不得不先查詢完整的資料,然後再篩選,這無疑浪費了頻寬。當然這種情況下我們可以直接查詢redis,但是無疑又提公升了一些複雜性。

順便說一句,memcached支援multiget,可以實現類似pipelining的效果,但你要格外小心這裡面有關memcached的坑,也就是mulitiget無底洞問題。

redis在儲存hash的時候,多儲存乙個名為「all」的字段,其內容是原hash資料的序列化,實際查詢的時候,只要hget這個冗餘欄位後再反序列化即可。此方案的優勢在於通過序列化字段冗餘,我們把原本的hgetall操作簡化為hget,也就是說,不再需要遍歷hash中的每乙個字段,因此即便不能讓多個cpu參與運算,但是卻大幅降低了運算元量,所以效能的提公升仍然是顯著的;當然劣勢也很明顯,和所有的冗餘方式一樣,此方案浪費了大量的記憶體。

有人會問,這樣雖然沒有了遍歷欄位的過程,但是卻增加了反序列化的過程,而反序列化的成本往往也是很高的,難道這樣也能提公升效能?問題的關鍵在於開始我們遍歷欄位的操作是在乙個cpu上完成的,後來反序列化的操作,不管是什麼語言,都可以通過多程序或多執行緒來保證是在多個cpu上完成的,所以效能總體上是提公升的。

…另外,很多人直覺是通過執行redis多例項來解決問題。確實,這樣可以增加運算過程中的cpu數量,有助於提公升效能,但是需要注意的是,hgetall和pipelining往往會讓運算過程中的運算元量呈幾何級**式增長,相比之下,我們能增加的redis多例項數量簡直就是杯水車薪,所以本例中這種方法不能徹底解決問題。

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

記Redis那坑人的HGETALL

世上本沒有坑,摔的人多了,也便成了坑。早就聽人說過redis的hgetall是個坑,可我偏偏不信邪 不管什麼坑,一定要自己踩上去跺兩腳才肯罷休。說好聽點這是不到黃河心不死,說難聽點就是不見棺材不落淚。開始程式執行的非常穩定,穩定到我想送所有說hgetall是個坑的人乙個字 呸!此時的我就像溫水裡的青...

記Redis那坑人的HGETALL

分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!世上本沒有坑,摔的人多了,也便成了坑。早就聽人說過redis的hgetall是個坑,可我偏偏不信邪 不管什麼坑,一定要自己踩上去跺兩腳才肯罷休。說好聽點這是不到黃河心不死,說難聽點就是不見棺材不落淚。開始程式執行的非常穩定,穩定到我想送所有說hge...

坑人的開發 記一次私活的坑人經歷

從忙碌的畢業前夕熬到了畢業,心力交瘁。離別的傷感,喝到昏天黑地的聚會,好像就在昨天。言歸正傳,畢業之前的幾天,也沒什麼事情了,正好上海一朋友介紹一活,幫忙做個專案的客戶端程式,基本上說是有2千多酬勞,感覺還可以,就答應了。於是,忙活了幾天。初期,由於資料實在太少,進度比較慢。後來經過一些特殊手段,得...