前面說了Redis的應用場景，可以說緩存技術（不僅是Redis）主要是為提高應用性能，緩解數據庫壓力而誕生的。但是每種技術都有適合自己的應用場景，也會有不適合自己的場景，沒有萬金油的技術。那麼那些場景不適合使用Redis呢？
1，從數據規模角度
從數據規模的角度來看，數據可以分為大規模數據和小規模數據。我們知道Redis是將數據存在內存中，目前來講，相對於磁盤而言內存還是比較貴的，如果將大規模數據全放在內存裡，成本上考慮還是不合適的。而且據我所知，現在運維上內存擴容還是要停機的，磁盤可以在線擴容。
2，從冷熱數據的角度
很多業務數據可以分為冷數據和熱數據。熱數據就是應用需要頻繁使用的數據。如果將大量的冷數據放在內存裡，那就是對內存的一種浪費。所以應該從業務場景上區分出冷熱數據，區別對待。只將熱數據放在內存中，加速數據讀寫，也可降低後端存儲的壓力。
另外在使用上，Redis的運維同樣重要。很多使用 Redis 的開發者認為只要會用 API 開發相應的功能就可以，更有甚者認為 Redis 就是 get、set、del，不需要知道 Redis 的原理。很多線上的故障和問題都是由於完全把 Redis 當做黑盒造成的，如果不瞭解 Redis 的單線程模型，有些開發者會在有上千萬個鍵的 Redis 上執行 keys*操作，如果不瞭解持久化的相關原理，會在一個寫操作量很大的 Redis 上配置自動保存 RDB。而且在很多公司內只有專職的關係型數據庫 DBA，並沒有 NoSQL 的相關運維人員，也就是說開發者很有可能會自己運維 Redis，對於 Redis 的開發者來說既是好事又是壞事。站在好的方面看，開發人員可以通過運維 Redis 真正瞭解 Redis 的一些原理，不單純停留在開發上。站在壞的方面看，Redis 的開發人員不僅要支持開發，還要承擔運維的責任，而且由於運維經驗不足可能會造成線上故障。但是從實際經驗來看，運維足夠規模的 Redis 會對用好 Redis 更加有幫助。
閱讀更多 IT技術圈 的文章
