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

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

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

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

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

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

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

轉載于:https://www.cnblogs.com/gzmg/p/4846483.html

總結

以上是生活随笔為你收集整理的[转]避免误用 Redis的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。