redis解决了什么问题？
大规模读写数据与数据库读写能力之间的矛盾                                 （推荐学习：redis视频教程）
简单回顾一下cpu高速缓存的发展历程，为了解决cpu的计算速度与内存的读取速度之间的巨大差异，cpu使用高速缓存来存放指令和数据。
高速缓存从最初的主板缓存到现在的3级缓存，缓存大小也不断变大。来自网络的数据表明：cpu高速缓存的命中率大约为80%。
类比电脑发展过程中cpu与内存的矛盾，可以察觉到大型网站中大规模读写数据与数据库读写能力之间的矛盾与此矛盾类似。我们也可以在数据库与应用之间构建一块比数据库速度更快存储区域——缓存。
大家最熟悉的也莫过于ｒｅｄｉｓ用作缓存，我们知道redis的作者设计redis的初衷是因为他使用关系型数据库时，无论如何优化，性能都不能达到自己的期望，于是便自己手写了一个内存数据库。
在作为缓存的情况下，我们有一下应用场景：
1. 热点数据 例如我们可以将sｑｌ查询结果保存在内存中，也可以将用户经常查看的图片保存在内存中。
2. 排行榜 基于redis提供的zset这种数据结构我们可以更加便捷的实现排行榜。实现排行榜的相关内容可以参考排行榜算法设计实现比较。在小规模数据的情况下，使用mysql实现排行榜没有多少问题，但是一旦数据量上去了，那么持续的进行mysql读写将会成为瓶颈。
3. 计数器/限速器 计数器的应用场景之一是统计用户的点赞数，限速器的应用场景之一是限制用户ip的访问次数。之所以redis能用于计数器是因为redis是单线程的，每次都必须前一个指令执行完，再执行下一个指令。这样就保证不会同时执行多条指令；也即不会出现并发问题。限速器的原理类似。
4. 共同好友 利用redis提供的set数据结构的求交集操作sinter可以更加便捷地求两个set集合的交集；而使用数据库的连表查询将造成性能的开销很多，因为大型网站的用户数量巨大。
5. 简单消息队列 redis的提供的发布/订阅是一个极其简单的消息系统。它不像kafka那样提供了分成不同的topic并且分成不同的分区并且提供持久化的功能。ｒｅｄｉｓ的消息队列用在不需要高可靠的场景。
6. session共享 session是用来记录是用户是谁。当在应用使用集群方式部署的时候，我们需要一个统一管理session的地方，可以使用数据库来记录session，但是这时对数据库的性能要求较高，此外session通常是具有时效性的，这段逻辑我们需要在代码中实现，但是如果使用redis来共享session，那么不会出现这样的问题。
上面的许多应用场景也可以使用其他技术解决问题，只是redis这样的技术在一定资源限制的情况下，会是更好的解决方案。
更多redis相关技术文章，请访问redis数据库使用入门教程栏目进行学习！
以上就是什么情况下使用redis缓存的详细内容。