分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！
世上本沒有坑，摔的人多了，也便成了坑。
早就聽人說過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多例項數量簡直就是杯水車薪，所以本例中這種方法不能徹底解決問題。
坑，就是用來踩的。不用怕掉進去，當然前提是你能自己爬出來！
給我老師的人工智慧教程打call！
記Redis那坑人的HGETALL
世上本沒有坑，摔的人多了，也便成了坑。早就聽人說過redis的hgetall是個坑，可我偏偏不信邪 不管什麼坑，一定要自己踩上去跺兩腳才肯罷休。說好聽點這是不到黃河心不死，說難聽點就是不見棺材不落淚。開始程式執行的非常穩定，穩定到我想送所有說hgetall是個坑的人乙個字 呸！此時的我就像溫水裡的青...
記Redis那坑人的HGETALL
世上本沒有坑，摔的人多了，也便成了坑。早就聽人說過redis的hgetall是個坑，可我偏偏不信邪 不管什麼坑，一定要自己踩上去跺兩腳才肯罷休。說好聽點這是不到黃河心不死，說難聽點就是不見棺材不落淚。開始程式執行的非常穩定，穩定到我想送所有說hgetall是個坑的人乙個字 呸！此時的我就像溫水裡的青...
坑人的開發 記一次私活的坑人經歷
從忙碌的畢業前夕熬到了畢業，心力交瘁。離別的傷感，喝到昏天黑地的聚會，好像就在昨天。言歸正傳，畢業之前的幾天，也沒什麼事情了，正好上海一朋友介紹一活，幫忙做個專案的客戶端程式，基本上說是有2千多酬勞，感覺還可以，就答應了。於是，忙活了幾天。初期，由於資料實在太少，進度比較慢。後來經過一些特殊手段，得...