避免誤用 Redis

　　Redis 是目前 NoSQL 領域的當紅炸子雞，它象一把瑞士軍刀，小巧、鋒利、實用，特別適合解決一些使用傳統關聯式資料庫難以解決的問題。但是 Redis 不是銀彈，有很多適合它解決的問題，但是也有很多並不適合它解決的問題。另外，Redis 作為記憶體資料庫，如果用在不適合的場合，對記憶體的消耗是很可觀的，甚至會讓系統難以承受。

 

　　我們可以對系統儲存使用的資料以兩種角度分類，一種是按資料的大小劃分，分成大資料和小資料，另一種是按資料的冷熱程度劃分，分成冷資料和熱資料，熱資料是指讀或寫比較頻繁的資料，反之則是冷資料。

　　可以舉一些具體的例子來說明資料的大小和冷熱屬性。比如網站總的註冊使用者數，這明顯是一個小而熱的資料，小是因為這個資料只有一個值，熱是因為註冊使用者數隨時間變化很頻繁。再比如，使用者最新訪問時間資料，這是一個量比較大，冷熱不均的資料，大是資料的粒度是使用者級別，每一個使用者都有資料，如果有一千萬使用者，就意味著有一千萬的資料，冷熱不均是因為活躍使用者的最新訪問時間變化很頻繁，但是可能有很大一部非活躍使用者訪問時間長時間不會發生變化。

　　大體而言，Redis 最適合處理的是小而熱，而且是寫頻繁，或者讀寫都比較頻繁的熱資料。對於大而熱的資料，如果其它方式很難解決問題，也可以考慮使用 Redis 解決，但是一定要非常謹慎，防止資料無限膨脹。原因如下：

　　首先，對於冷資料，無論大小，都不建議放在 Redis 中。Redis 資料要全部放在記憶體中，資源寶貴，把冷資料放在其中實在是一種浪費，冷資料放在普通的儲存比如關聯式資料庫中就好了。

　　其次，對於熱資料，尤其是寫頻繁的熱資料，如果量比較小，是最適合放到 Redis 中的。比如上面提到的網站總的註冊使用者數，就是典型的 Redis 用做計數器的例子。再比如論壇最新發表列表，最新報名列表，可以控制數量在幾百到一千的規模，也是典型的 redis 做最新列表的使用方式。

　　另外，對於量比較大的熱資料（或者冷熱不均資料），使用 Redis 時一定要比較謹慎。這種型別資料很容易引起資料膨脹，導致 Redis 消耗記憶體巨大，讓系統難以承受。薄荷的一個慘痛教訓是把使用者關注（以及被關注）資料放在 Redis 中，這是一種資料量極大，冷熱很不均衡的資料，在幾百萬的使用者級別就佔用了近 10 GB左右記憶體，讓 Redis 變得難以應付。應對這種型別的資料，可以用普通儲存 + 快取的方式。

　　如果用對了地方，比如在小而熱的資料情形，Redis 表現很棒，如果用錯了地方，Redis 也會帶來昂貴的代價，所以使用時務必謹慎。