redis的hGetAll函數的效能問題(記Redis那坑人的HGETALL)_Redis

在沒關注這個函數之前，一直用的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

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

早就聽人說過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多執行個體數量簡直就是杯水車薪，所以本例中這種方法不能徹底解決問題。

…

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