用Redis搞定网站缓存，速度快还省资源的那些事儿

说到给网站提速，Redis可是个绕不开的大宝贝，它就像一个超级能干的“临时工”，把那些经常要用、又不用每次都去数据库里翻箱倒柜找的数据，暂时存放在自己这儿，这样一来，网站响应速度嗖嗖的，服务器压力也小了不少，咱们今天就来聊聊，怎么用这个“临时工”把网站的缓存搞得又快又省心。

为啥非得是Redis？它到底快在哪儿？

Redis最厉害的地方，就是它把数据都放在内存里，内存的读写速度，跟硬盘比起来，那简直就是高铁和自行车的区别，你想想，用户点开一个网页，如果需要展示的商品信息、用户信息都得去硬盘上的数据库里现找，那肯定快不了，但要是这些信息已经提前在内存里准备好了，直接拿出来用，速度自然就上去了，根据菜鸟教程的说明，Redis能支持每秒十几万次的读写操作,这性能对付绝大多数网站都绰绰有余了。

Redis不只是个简单的键值对仓库，它支持好几种数据结构，比如字符串（String）、列表（List）、集合（Set）、有序集合（Sorted Set）和哈希（Hash），这就很灵活了，你想缓存一篇文章详情，可以用String结构；想缓存文章的最新十条评论，可以用List；想统计一下文章的独立访客数，避免重复计数，用Set就特别合适，这种灵活性让我们可以根据不同的业务场景，选择最合适的缓存方式,效率更高。

实战：Redis在网站里最常见的几种用法

1. 缓存热点数据，减轻数据库压力 这是Redis最经典的应用，比如一个电商网站，首页上展示的热销商品信息、轮播图内容等，这些数据可能很长时间才变更一次，但每个用户进来都要访问，如果每次请求都去查询数据库，MySQL（或其他数据库）的压力会非常大，这时候，我们就可以在商品信息更新后，同时把它也塞到Redis里，并设置一个过期时间（比如10分钟），接下来的10分钟内，所有用户请求商品信息，都直接从Redis里取，数据库那边就轻松了，网站响应也快，等10分钟过期后，再从数据库查一次，更新到Redis，这就是所谓的“缓存失效”策略。

2. 会话存储（Session Storage） 用户登录后，服务器需要记住他是谁，传统的做法是把Session信息存在服务器自己的内存里，但这样有个问题：如果网站用了多台服务器做负载均衡，用户下一次请求可能被分配到另一台机器上，那台机器就没有他的登录信息，导致用户“被下线”了，解决这个问题，可以把Session统一存到Redis里，所有的服务器都来访问这个中央的Redis，这样无论用户跑到哪台服务器，都能认出他来，京东技术团队曾分享过他们使用Redis实现分布式Session的实践,保证了大规模用户同时在线时的体验一致性。

3. 应对突发的高并发访问（缓存穿透、雪崩、击穿） 这几个词听着吓人，其实道理不难，缓存穿透”，指的是有人恶意请求根本不存在的数据（比如商品ID=-1），因为缓存里没有，请求就直接打到数据库上了，可能导致数据库瘫痪，对付这招，可以在Redis里也缓存一下“空结果”，告诉系统“这东西没有”，下次同样的无效请求来了，直接返回空，别再去烦数据库了。 再比如“缓存雪崩”，指的是同一时间，大量缓存数据集体过期，所有请求瞬间涌向数据库，解决办法可以给不同的缓存数据设置稍微随机一点的过期时间，避免它们同时失效，而“缓存击穿”是指一个非常热点的数据过期时，大量请求同时涌来去数据库重建缓存，对这个，可以用Redis的setnx命令做个简单的互斥锁，只让一个请求去查数据库，其他请求等着,等缓存重建好了大家再用。

4. 实现简单的消息队列 有些任务不用立即完成，可以慢慢来，比如用户注册成功后发一封欢迎邮件，这种任务可以把它扔进Redis的List结构里，作为一个队列，然后后台跑一个worker程序，不停地从队列里取任务出来执行，这样主网站流程就能快速响应给用户，把耗时的操作异步化处理，虽然专业的消息队列如RabbitMQ功能更强大，但对于简单的场景，Redis的List或Pub/Sub功能完全够用,非常轻量。

用Redis也不是一劳永逸，有些坑得留心

虽然Redis很强，但用不好也会出问题，内存毕竟比硬盘贵，所以不能什么都往Redis里塞，得精打细算，只缓存那些真正“热”的数据，一定要给缓存数据设置合理的过期时间，不然旧数据会一直占着地方，还要做好数据持久化配置（比如RDB快照或AOF日志），防止服务器重启或者宕机时数据全部丢失，如果数据量特别大,可能还需要搭建Redis集群来分担压力。

把Redis用好了，就像是给网站请了一个反应神速的前台，它能帮你处理掉大部分简单又重复的查询，让你的核心数据库（好比是后台的专家团队）能专注于处理更复杂的任务，这一前一后搭配好了，网站的速度和承载能力自然就上了一个大台阶，用户体验好了，运营成本也可能降下来,确实是一件双赢的好事儿。