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

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

PERFORMANCE = CPUs / OPERATIONs

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

例如：

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

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

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

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

總結

以上是生活随笔為你收集整理的redis的hGetAll函数的性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

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