在沒關(guān)注這個(gè)函數(shù)之前，一直用的Memcache的數(shù)據(jù)存儲(chǔ)方式，但是自從更換了redis之后，對(duì)于一個(gè)hash的數(shù)據(jù)存與取 對(duì)于Memcache方便甚多，但是問題來了，一個(gè)hash的列表如果量不大的情況，用hGetAll函數(shù)幾乎看不出問題，一旦這個(gè)列表超過50或者更多時(shí)，此時(shí)用hGetAll函數(shù)便能很直觀的看到性能問題，這里就不作數(shù)據(jù)分析了。
Redis是單線程的！當(dāng)它處理一個(gè)請(qǐng)求時(shí)其他的請(qǐng)求只能等著。通常請(qǐng)求都會(huì)很快處理完，但是當(dāng)我們使用HGETALL的時(shí)候，必須遍歷每個(gè)字段來獲取數(shù)據(jù)，這期間消耗的CPU資源和字段數(shù)成正比，如果還用了PIPELINING，無疑更是雪上加霜。
復(fù)制代碼 代碼如下:
PERFORMANCE = CPUs / OPERATIONs
也就是說，此場(chǎng)景下為了提升性能，要么增加運(yùn)算過程中的CPU數(shù)量；要么降低運(yùn)算過程中的操作數(shù)量。在為了繼續(xù)使用hash結(jié)構(gòu)的數(shù)據(jù)，又要解決此問題，比較方便的方法就是將hash以序列化字符串存儲(chǔ)，取的時(shí)候先取出反序列化的數(shù)據(jù)，再用hGet(key,array(hash..))。
例如：
復(fù)制代碼 代碼如下:
....
$arrKey = array('dbfba184bef630526a75f2cd073a6098','dbfba184bef630526a75f2cd0dswet98')
$strKey = 'test';
$obj->hGet($strKey,$arrKey);
把原本的hGetAll操作簡(jiǎn)化為hGet，也就是說，不再需要遍歷hash中的每一個(gè)字段，因此即便不能讓多個(gè)CPU參與運(yùn)算，但是卻大幅降低了操作數(shù)量，所以性能的提升仍然是顯著的；當(dāng)然劣勢(shì)也很明顯，和所有的冗余方式一樣，此方案浪費(fèi)了大量的內(nèi)存。
有人會(huì)問，這樣雖然沒有了遍歷字段的過程，但是卻增加了反序列化的過程，而反序列化的成本往往也是很高的，難道這樣也能提升性能？問題的關(guān)鍵在于開始我們遍歷字段的操作是在一個(gè)cpu上完成的，后來反序列化的操作，不管是什么語言，都可以通過多進(jìn)程或多線程來保證是在多個(gè)cpu上完成的，所以性能總體上是提升的。
另外，很多人直覺是通過運(yùn)行redis多實(shí)例來解決問題。確實(shí)，這樣可以增加運(yùn)算過程中的CPU數(shù)量，有助于提升性能，但是需要注意的是，hGetAll和PIPELINING往往會(huì)讓運(yùn)算過程中的操作數(shù)量呈幾何級(jí)爆炸式增長(zhǎng)，相比之下，我們能增加的redis多實(shí)例數(shù)量簡(jiǎn)直就是杯水車薪，所以本例中這種方法不能徹底解決問題。
記Redis那坑人的HGETALL
世上本沒有坑，摔的人多了，也便成了坑。
早就聽人說過Redis的HGETALL是個(gè)坑，可我偏偏不信邪：不管什么坑，一定要自己踩上去跺兩腳才肯罷休。說好聽點(diǎn)這是不到黃河心不死，說難聽點(diǎn)就是不見棺材不落淚。
開始程序運(yùn)行的非常穩(wěn)定，穩(wěn)定到我想送所有說HGETALL是個(gè)坑的人一個(gè)字：呸！此時(shí)的我就像溫水里的青蛙一樣忘記了危險(xiǎn)的存在，時(shí)間就這樣一天一天的過去，突然有一天需求變了，我不得不把HASH數(shù)據(jù)的內(nèi)容從十幾個(gè)字段擴(kuò)展到一百多個(gè)字段，同時(shí)使用了Pipelining一次性獲取上百個(gè)HGETALL的結(jié)果。于是我掉坑里了：服務(wù)器宕機(jī)。
為什么會(huì)這樣？Redis是單線程的！當(dāng)它處理一個(gè)請(qǐng)求時(shí)其他的請(qǐng)求只能等著。通常請(qǐng)求都會(huì)很快處理完，但是當(dāng)我們使用HGETALL的時(shí)候，必須遍歷每個(gè)字段來獲取數(shù)據(jù)，這期間消耗的CPU資源和字段數(shù)成正比，如果還用了PIPELINING，無疑更是雪上加霜。
如何解決這個(gè)問題？請(qǐng)容許我煞有其事的給出一個(gè)公式：
復(fù)制代碼 代碼如下:
PERFORMANCE = CPUs / OPERATIONs
也就是說，此場(chǎng)景下為了提升性能，要么增加運(yùn)算過程中的CPU數(shù)量；要么降低運(yùn)算過程中的操作數(shù)量。具體來說，我大致想到了以下幾種方法：
借助Memcached
Redis存儲(chǔ)方式不做任何改變，額外的，我們借助Memcached實(shí)現(xiàn)一套緩存，里面存儲(chǔ)原本需要在Redis里HGETALL的HASH，當(dāng)然，由于Memcached里存儲(chǔ)的都是字符串，所以當(dāng)我們存儲(chǔ)HASH的時(shí)候，實(shí)際上存儲(chǔ)的是HASH序列化后的字符串，查詢的時(shí)候再反序列化即可，通常Memcached客戶端驅(qū)動(dòng)可以透明實(shí)現(xiàn)序列化和反序列化的過程。此方案的優(yōu)勢(shì)在于因?yàn)镸emcached支持多線程，所以可以讓更多的CPU參與運(yùn)算，同時(shí)由于不用再遍歷每一個(gè)字段，所以相應(yīng)的操作會(huì)減少；當(dāng)然劣勢(shì)也不少，因?yàn)橐肓艘粋€(gè)新的緩存層，所以浪費(fèi)了內(nèi)存，增加了復(fù)雜性，另外，有時(shí)候即便我們只需要獲取少數(shù)幾個(gè)字段的數(shù)據(jù)，也不得不先查詢完整的數(shù)據(jù)，然后再篩選，這無疑浪費(fèi)了帶寬。當(dāng)然這種情況下我們可以直接查詢Redis，但是無疑又提升了一些復(fù)雜性。
順便說一句，Memcached支持Multiget，可以實(shí)現(xiàn)類似Pipelining的效果，但你要格外小心這里面有關(guān)Memcached的坑，也就是Mulitiget無底洞問題。
序列化字段冗余
Redis在存儲(chǔ)HASH的時(shí)候，多保存一個(gè)名為「all」的字段，其內(nèi)容是原HASH數(shù)據(jù)的序列化，實(shí)際查詢的時(shí)候，只要HGET這個(gè)冗余字段后再反序列化即可。此方案的優(yōu)勢(shì)在于通過序列化字段冗余，我們把原本的HGETALL操作簡(jiǎn)化為HGET，也就是說，不再需要遍歷HASH中的每一個(gè)字段，因此即便不能讓多個(gè)CPU參與運(yùn)算，但是卻大幅降低了操作數(shù)量，所以性能的提升仍然是顯著的；當(dāng)然劣勢(shì)也很明顯，和所有的冗余方式一樣，此方案浪費(fèi)了大量的內(nèi)存。
有人會(huì)問，這樣雖然沒有了遍歷字段的過程，但是卻增加了反序列化的過程，而反序列化的成本往往也是很高的，難道這樣也能提升性能？問題的關(guān)鍵在于開始我們遍歷字段的操作是在一個(gè)CPU上完成的，后來反序列化的操作，不管是什么語言，都可以通過多進(jìn)程或多線程來保證是在多個(gè)CPU上完成的，所以性能總體上是提升的。
…
另外，很多人直覺是通過運(yùn)行Redis多實(shí)例來解決問題。確實(shí)，這樣可以增加運(yùn)算過程中的CPU數(shù)量，有助于提升性能，但是需要注意的是，HGETALL和PIPELINING往往會(huì)讓運(yùn)算過程中的操作數(shù)量呈幾何級(jí)爆炸式增長(zhǎng)，相比之下，我們能增加的Redis多實(shí)例數(shù)量簡(jiǎn)直就是杯水車薪，所以本例中這種方法不能徹底解決問題。
…
坑，就是用來踩的。不用怕掉進(jìn)去，當(dāng)然前提是你能自己爬出來！
您可能感興趣的文章:- Python使用Redis實(shí)現(xiàn)作業(yè)調(diào)度系統(tǒng)(超簡(jiǎn)單)
- PHP的Laravel框架結(jié)合MySQL與Redis數(shù)據(jù)庫(kù)的使用部署
- php基于redis處理session的方法
- Linux下Redis的安裝和部署
- Java連接Vmware中的redis
- Nginx配置srcache_nginx模塊搭配Redis建立緩存系統(tǒng)
- 在CenOS系統(tǒng)下安裝和配置Redis數(shù)據(jù)庫(kù)的教程
- C++訪問Redis的mset 二進(jìn)制數(shù)據(jù)接口封裝方案
- C++開發(fā)的Redis數(shù)據(jù)導(dǎo)入工具優(yōu)化
- 淺談Redis在分布式系統(tǒng)中的協(xié)調(diào)性運(yùn)用
