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

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

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

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

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

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

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

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