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

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

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

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

首先，對于冷數據，無論大小，都不建議放在 Redis 中。Redis 數據要全部放在內存中，資源寶貴，把冷數據放在其中實在是一種浪費，冷數據放在普通的存儲比如關系數據庫中就好了。

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

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

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