小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
最佳场景——小容量、热数据
由于redis使用的纯内存储存，提供的是更高性能以及更好可用 性的缓存系统。所以，从成本、资源利用率以及缓存系统特性来说，Squirrel更加适合存储一些热数据——即经常被访问的数据可以存储在redis中。我们希望的是redis中的绝大部分数据是一天内是会被全部访问到的，对于大量的超过几天时间都不会访问的数据存储在redis里面则比较浪费。
最佳实践与需要注意的坑
选择合适的数据结构
Redis原生支持String、Hash、Set、SortedSet、List等数据结构以支持复杂的场景需求 。Redis数据结构简介
杜绝大Value，热点Key
比如String类型的value超过512KB，Hash、Set、Zset、List这些集合类型的元素超过1W个，大Value的拆分参考
热点key容易造成CPU、网络上的高负载。建议业务对热点key有降级方案
单集群Key个数 < 1亿
Key个数过多会消耗大量的额外内存 多Key的合并方式参考
主动更新缓存
被动更新可能会给DB带来压力。推荐可以通过订阅数据库的变更或者其他方式来更新缓存中的key
关注集群内存
内存在满载情况会对业务有明显的性能影响。建议在集群内存占用较高的时候一是尝试优化），二是联系DBA进行扩容操作。
设置合理的过期时间
1，key的过期时间应该尽量的短，减少内存占用；2，避免出现大量key同时过期的
使用multiGet或者pipeline提速
使用multiGet或者 pipeline能够将多次的缓存操作合并到一次网络请求中，大大减少网络开销。
避免复杂操作
multi以及pipeline等批量操作中的key个数不要太多，避免使用复杂度为O(N)的集合类操作，比如Hgetall。
multi，pipeline，hgetall 如何选择？ 如果本身key 不超过 100 ， 建议存放在 hash中， hash批量获取可以减少网络IO （只获取一个key 和 获取多个key 的区别）
不要过度使用
比如不要使用list去做消息队列，Redis不保证这些功能的可靠性。有这类需求的可以去使用架构的其他组件，专业的事由专业的组件做
