Redis到底能用在哪些场景啊，感觉它好像无处不在又说不上具体哪里特别重要

Redis这个东西，确实像你说的，感觉无处不在，但又很难一下子说清楚它到底在哪个环节起了决定性作用，这其实是因为Redis很少作为一个独立的核心业务系统（比如数据库）来用，它更像是一个无处不在的“超级帮手”，专门负责处理那些让传统数据库头疼的零碎活、快活、累活，它的核心价值就两个字：快和灵。

下面我就具体说说它都在哪些地方“打工”。

第一个最经典，也是最能体现它“快”的场景：缓存。 这是Redis的看家本领，绝大多数人第一次认识Redis就是因为这个，想象一下一个电商网站的商品详情页，每次用户打开页面，系统都需要从MySQL这类数据库中查询商品信息、库存、价格等等，如果每次请求都直接砸向数据库，数据库压力会巨大无比，而且查询速度也快不起来，尤其是热门商品，可能每秒有上万个人在看，这时候，Redis就派上用场了，系统可以第一次从数据库查出商品数据后，顺手就把它丢到Redis里，并设置一个过期时间（比如5分钟），接下来的5分钟内，所有用户再来访问这个商品页，系统就直接从Redis里拿数据，速度比查数据库快几十甚至上百倍，这就好比你在书桌上放了一个常用文件的文件夹（Redis），而不是每次都要跑去档案室（数据库）翻找，效率自然大大提升，等5分钟过期后，再从数据库查一次更新到Redis，保证数据不会太旧，根据Redis官方文档和大量技术博客的普遍描述,缓存是其最基础且占比最高的应用。

第二个场景是“计数器”和排行榜。 社交网站上的点赞数、阅读量，视频的播放次数，这些数字需要频繁地更新——每次有人点赞，数字就要加1，如果每次加1都去写数据库，数据库的磁盘I/O会受不了，而Redis是直接把数据放在内存里操作的，对数字进行增加减少这类操作速度极快，它有一个命令叫INCR，专门用于原子性地给一个值加1，完美契合计数需求，基于这个计数功能，实现排行榜就很简单了，比如一个游戏里的玩家积分榜，可以用Redis的“有序集合”结构，把玩家ID和分数存进去，它能自动按分数排序，你要查全球前十名，一个命令就能瞬间拿到结果，微博的热搜榜、游戏的实时排名,背后基本都是Redis在支撑。

第三个场景是会话管理。 你现在登录了一个网站，服务器需要记住你是谁，这个“的状态就是会话（Session），在传统的做法里，Session可能存在服务器自己的内存或者文件里，但这会带来一个问题：当网站有很多台服务器做负载均衡时，你第一次访问被分到A服务器登录了，第二次请求可能被分到B服务器，B服务器上没有你的登录信息，就会要求你重新登录，体验很差，解决方法是把Session放在一个所有服务器都能访问的中央仓库里，Redis就是这个仓库的绝佳选择，因为它快，存取得快，而且可以设置自动过期，正好对应Session的过期需求，这样无论用户的请求被分配到哪台服务器，都能从Redis里拿到统一的登录状态，根据多位资深工程师在技术社区（如知乎、Stack Overflow）的分享,使用Redis进行分布式Session管理是中型以上互联网应用的常见做法。

第四个场景是消息队列。 这个可能有点出乎意料，但Redis确实能当简单的消息队列用，比如一个下单流程，用户点击下单后，核心任务是创建订单、扣减库存，但可能还有一些不那么紧急的“后续任务”，比如给用户发个通知短信、给运营人员发个提示、更新一下统计数据等等，如果把这些事都放在下单的主流程里一起做，用户就得等着所有事都干完才能看到结果，体验不好，更聪明的做法是，订单创建成功后，只是往Redis的一个列表里“推送”一个消息，内容可能是“订单XXX已创建”，专门负责发短信的程序、负责统计的程序，不停地从Redis这个列表里“拉取”消息来处理，这样，下单的主流程就变得非常轻快，实现了“异步处理”，虽然专业的消息队列软件（如Kafka、RabbitMQ）功能更强大，但在很多对可靠性要求不是极端高的场景下,用Redis实现轻量级的消息队列非常方便快捷。

第五个场景是实时系统。 比如网络聊天室、直播间的弹幕，这种场景的特点是数据量可能不大，但要求极高的实时性，一条消息发出后，需要在几十毫秒内广播给在线的成千上万人，用数据库来存然后再查是完全不可行的，速度太慢，Redis的发布订阅功能就非常适合，一个人发送消息，就是向一个“频道”发布消息，所有订阅了这个频道的人（他们的网络连接对应的服务器程序）会立刻收到这条消息，再由服务器推送到用户的浏览器或App上,这个过程几乎感觉不到延迟。

第六个场景是处理复杂数据结构。 有时候我们需要缓存的数据不是简单的键值对，要缓存一个用户的个人资料，里面包含姓名、年龄、城市、兴趣爱好列表等等，如果用普通的键值存储，可能需要序列化成JSON字符串再存，但Redis支持哈希结构，可以像在程序里操作对象一样，直接修改用户资料的某一个字段（比如只更新城市），而不用读取整个对象，非常灵活，再比如，要记录用户最近浏览的10个商品，可以用Redis的列表结构，每次浏览就往里添加一个新商品ID，如果超过10个就把最早的挤出去,实现起来非常简单。

回到你的问题，Redis之所以感觉“无处不在又说不上特别重要”，是因为它扮演的是一个性能加速器和架构润滑剂的角色，它不直接创造核心业务数据（那是数据库的事），但它通过承担大量高并发、实时性的小任务，保证了核心系统（数据库）能够稳定、高效地运行，没有它，很多互联网应用可能也能工作，但用户体验会大打折扣，系统可能会在流量稍大时就崩溃，它的“特别重要”就体现在这里：它可能不是舞台上的主角,但绝对是确保整场演出流畅进行的王牌配角。