大数据量用Redis存储，效率蹭蹭往上涨，Redis到底适合啥场景？

主要综合自知乎专栏“Redis为什么这么快？”、博客园文章“Redis应用场景全解析”以及CSDN技术博客“大数据环境下Redis的实战经验”中的观点和案例）

说到处理大数据量,很多人的第一反应是上Hadoop、Spark这些大家伙，觉得它们才是正解，但实际情况是，很多时候，先把Redis用对了，效率就能立竿见影地提上来，因为它实在是太快了，Redis就像一个超级快的临时记忆库，数据放进去、拿出来几乎不花时间，它到底在哪些场景下能大显身手，让效率“蹭蹭蹭”地往上窜呢？

最经典、最普遍的场景就是缓存，这可以说是Redis的老本行，想象一下，一个热门网站，每天有上百万人访问首页，如果每次有人点进来，系统都去庞大的主数据库（比如MySQL）里查一次首页需要的数据，那数据库的压力得有多大，速度肯定快不起来，这时候，Redis就派上用场了，我们可以把首页需要的数据，比如热门文章列表、用户的基本信息、广告位配置等，第一次从数据库查出来之后，顺手就存一份到Redis里，并且设置一个合理的过期时间（比如5分钟），接下来的5分钟内，所有用户再来访问首页，系统就直接从Redis里拿数据，速度比直接查数据库快几十甚至上百倍，数据库的压力瞬间就降下来了，网页打开速度也飞快，这就是缓存的力量，Redis凭借其超高的读写速度，完美胜任了这个角色。

是那种需要高速计数的场景，在互联网应用里，计数无处不在：文章的阅读量、用户的点赞数、微博的转发数、商品的库存量……这些数字的特点是需要频繁地更新，每秒可能有成千上万次的操作，如果每次点赞都直接去数据库里“UPDATE table SET count = count + 1”，数据库的磁盘IPS会很快成为瓶颈，而Redis天然支持这种原子性的增加减少操作（INCR, DECR命令），它把所有数据都放在内存里操作，速度极快，你可以为每一篇文章设置一个键叫“article:123:views”，每次有人阅读，就执行一次INCR命令，需要显示阅读量时，直接读取这个键的值就行，这种简单粗暴的方式，对于处理海量的计数请求非常有效。

再来一个很重要的场景,就是存储会话（Session），特别是对于分布式部署的网站，用户可能这次请求发到A服务器，下次请求就发到了B服务器，如果会话信息（比如用户登录状态、购物车信息）只存在单台服务器的内存里，那用户就会莫名其妙地掉线，传统的解决办法是把Session存到数据库，但这又回到了性能问题，Redis就成了一个完美的分布式Session存储中心，所有服务器都连接到同一个Redis集群，读写用户的Session信息，因为Redis快，用户完全感觉不到延迟；因为它是集中式的，解决了Session共享的问题。

除了这些,Redis还特别适合处理排行榜和热门列表，比如游戏里的玩家积分榜、视频网站的热门视频榜，Redis提供了一种叫“有序集合”（Sorted Set）的数据结构，可以轻松实现排序，你只需要把成员（比如用户ID）和分数（比如积分）放进去，它自动就帮你排好序了，而且可以非常高效地获取排名前N的成员、某个成员的排名等，这种操作如果靠数据库的“ORDER BY”来实现，数据量一大就会非常吃力。

还有像消息队列这种需要解耦系统组件的场景，虽然Redis不是专业的消息队列软件（比如RabbitMQ、Kafka），但它提供的列表（List）结构，支持简单的入队（LPUSH）和出队（RPOP）操作，对于业务逻辑不是极端复杂、但对速度要求很高的轻量级消息传递需求，完全够用，用户下单后，把订单信息推入一个Redis队列，后端的发货系统从这个队列里取任务处理，实现了下单和发货过程的异步化，提升了整体系统的响应速度。

不能忘了实时系统，比如实时监控、实时数据分析，在一些需要快速收集数据并展示统计结果的场景下，比如实时在线人数、实时的业务指标波动，Redis可以作为一个高速的数据暂存和计算层，数据先高速写入Redis，进行一些简单的聚合计算，然后再定期或批量地持久化到更稳定的数据库中，这样既保证了实时性，又确保了数据的最终安全。

Redis也不是万能的,它最大的特点是快，但这个快是建立在数据主要存放在内存的基础上的，这意味着，相比硬盘，内存的成本更高，所以你不能指望用Redis来存储所有的数据，它更适合存放那些需要被频繁访问的热点数据，虽然Redis有持久化机制可以把数据写到硬盘上以防丢失，但在极端情况下，它并不能像传统关系型数据库那样提供强一致性的保证。

当你遇到大数据量下,需要极快的读写速度、处理高并发访问、存储临时或热点数据的场景时，就应该优先考虑Redis，把它当作整个系统架构中的“高速服务区”或“缓存加速层”，让它负责最“繁忙”的那部分工作，从而解放后端的主数据库，让整个系统的效率真正“蹭蹭蹭”地涨上去。