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

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

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

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

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

PERFORMANCE = CPUs / OPERATIONs

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

借助Memcached

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多實例數量簡直就是杯水車薪，所以本例中這種方法不能徹底解決問題。

…

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

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的记Redis那坑人的HGETALL的全部內容，希望文章能夠幫你解決所遇到的問題。

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