Redis 是目前 NoSQL 領(lǐng)域的當(dāng)紅炸子雞张峰，它象一把瑞士軍刀，小巧棒旗、鋒利喘批、實用，特別適合解決一些使用傳統(tǒng)關(guān)系數(shù)據(jù)庫難以解決的問題。但是 Redis 不是銀彈饶深，有很多適合它解決的問題餐曹，但是也有很多并不適合它解決的問題。另外敌厘，Redis 作為內(nèi)存數(shù)據(jù)庫凸主，如果用在不適合的場合，對內(nèi)存的消耗是很可觀的额湘，甚至?xí)屜到y(tǒng)難以承受。
我們可以對系統(tǒng)存儲使用的數(shù)據(jù)以兩種角度分類旁舰，一種是按數(shù)據(jù)的大小劃分锋华，分成大數(shù)據(jù)和小數(shù)據(jù)，另一種是按數(shù)據(jù)的冷熱程度劃分箭窜，分成冷數(shù)據(jù)和熱數(shù)據(jù)毯焕，熱數(shù)據(jù)是指讀或?qū)懕容^頻繁的數(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 解決族扰，但是一定要非常謹(jǐn)慎，防止數(shù)據(jù)無限膨脹。原因如下：
首先渔呵，對于冷數(shù)據(jù)怒竿，無論大小，都不建議放在 Redis 中扩氢。Redis 數(shù)據(jù)要全部放在內(nèi)存中耕驰，資源寶貴，把冷數(shù)據(jù)放在其中實在是一種浪費录豺，冷數(shù)據(jù)放在普通的存儲比如關(guān)系數(shù)據(jù)庫中就好了朦肘。
其次，對于熱數(shù)據(jù)双饥，尤其是寫頻繁的熱數(shù)據(jù)媒抠，如果量比較小，是最適合放到 Redis 中的咏花。比如上面提到的網(wǎng)站總的注冊用戶數(shù)趴生，就是典型的 Redis 用做計數(shù)器的例子。再比如論壇最新發(fā)表列表昏翰，最新報名列表苍匆，可以控制數(shù)量在幾百到一千的規(guī)模，也是典型的 redis 做最新列表的使用方式棚菊。
另外浸踩，對于量比較大的熱數(shù)據(jù)（或者冷熱不均數(shù)據(jù)），使用 Redis 時一定要比較謹(jǐn)慎统求。這種類型數(shù)據(jù)很容易引起數(shù)據(jù)膨脹民轴，導(dǎo)致 Redis 消耗內(nèi)存巨大，讓系統(tǒng)難以承受球订。薄荷的一個慘痛教訓(xùn)是把用戶關(guān)注（以及被關(guān)注）數(shù)據(jù)放在 Redis 中后裸，這是一種數(shù)據(jù)量極大，冷熱很不均衡的數(shù)據(jù)冒滩，在幾百萬的用戶級別就占用了近 10 GB左右內(nèi)存微驶，讓 Redis 變得難以應(yīng)付。應(yīng)對這種類型的數(shù)據(jù)开睡，可以用普通存儲 + 緩存的方式因苹。
如果用對了地方，比如在小而熱的數(shù)據(jù)情形篇恒，Redis 表現(xiàn)很棒扶檐，如果用錯了地方，Redis 也會帶來昂貴的代價胁艰，所以使用時務(wù)必謹(jǐn)慎款筑。
