项目里用Redis提升性能那些事儿，怎么接入才靠谱又高效

说到在项目里用Redis提升性能,这事儿听起来高大上，但说白了就是找个“超级临时工”来帮数据库大哥分担压力，数据库大哥（比如MySQL）啥都好，就是有时候活儿太多，查点东西慢吞吞的，用户等着急，这时候，我们把一些经常要查、但又不太变化的数据，交给Redis这个“超级临时工”先拿着，下次再要的时候，直接找Redis拿，速度飞快。

Redis为啥能“提速”？它的三板斧

这得从Redis的本事说起,它主要靠三招吃饭，这也是我们决定用它的核心原因。

第一招是内存干活，Redis把所有数据都放在服务器的内存里，内存的读写速度比硬盘快成千上万倍，所以它响应请求的速度是微秒级别的，比数据库的毫秒级别快了一大截，这就好比你要找一本书，数据库得去图书馆的书架上慢慢找（磁盘I/O），而Redis就像你手边已经翻开的那本字典，随手就能翻到。（来源：Redis官方文档对内存存储的介绍）

第二招是简单的数据结构，Redis不像数据库表那么复杂，它提供了几种简单好用的“小盒子”来装数据，比如字符串（String）、列表（List）、集合（Set）、哈希（Hash）等，这些结构操作起来非常直接，没有数据库表连接那种弯弯绕绕，所以效率极高，我们要存一个用户的个人信息，用Hash结构，一个命令就能存进去，一个命令也能全取出来，非常利索。

第三招是避免重复劳动，这是提升性能最核心的思想，也就是我们常说的缓存，想象一个电商网站的商品详情页，每次有人访问都去数据库里查一遍商品信息、库存啥的，数据库压力山大，如果我们把第一次查到的结果丢到Redis里，设置一个过期时间（比如5分钟），那么接下来的5分钟内，所有用户来访问这个商品，都直接读Redis，数据库就彻底休息了，这就叫缓存命中，性能提升立竿见影。（来源：普遍的缓存设计模式）

怎么接入才算“靠谱又高效”？别瞎用

知道了Redis厉害,但乱用会出大事，轻则缓存没效果，重则把系统搞崩，接入时得抓住几个关键点。

选对“缓存策略”，这是灵魂

最常见的策略就是 “旁路缓存” ，这个策略很简单：

• 读数据：先查Redis，有就直接返回（命中）；没有就去查数据库，然后把结果写到Redis里，再返回。
• 写数据：直接更新数据库，然后删除Redis里对应的旧数据。

为啥是删除而不是更新Redis？这是为了简单和避免数据不一致的复杂问题，我先把旧数据清掉，下次有人读的时候，自然会从数据库把新数据加载进来，这个策略简单有效，是大多数场景的首选。（来源：Martin Fowler等技术专家推荐的缓存模式）

必须考虑“缓存穿透、击穿、雪崩”

这是三个经典坑,不处理好，Redis可能变成帮倒忙的。

• 缓存穿透：有人一直请求一个数据库里根本不存在的数据（比如查询id=-1的用户），每次请求都查不到缓存，就会一直去查数据库，相当于攻击了数据库。解决办法：如果数据库也查不到，就在Redis里存一个空值（比如"null"），并设置一个短的过期时间，这样短时间内的恶意请求就会命中这个空值，保护数据库。

• 缓存击穿：一个非常热点的数据（比如明星离婚公告）突然过期了，这时候海量请求同时涌来，全都发现缓存没了，于是全部去查数据库，瞬间把数据库打垮。解决办法：对热点数据不设置过期时间，或者用互斥锁，当第一个发现缓存失效的请求去查数据库时，加一把锁，其他请求等着，等它查到数据重建缓存后，其他请求直接从缓存读。

• 缓存雪崩：同一时刻，大量的缓存数据集体过期，导致所有请求都砸向数据库，引起数据库崩溃。解决办法：给不同的缓存数据设置随机的过期时间，比如基础是10分钟，然后加上一个0-5分钟的随机值，这样就能避免所有数据在同一时刻失效。

保证数据一致性，这是个权衡题

用了缓存,数据库和Redis里就有两份数据，怎么保证它们一样？上面提到的“旁路缓存”策略（写数据库后删缓存）是基础，但不能100%保证绝对一致（在极端并发下可能有小概率延迟），对于绝大多数业务场景，允许秒级的不一致是可以接受的，如果你的业务像银行转账一样要求强一致性，那技术方案会复杂得多，甚至可能不适合用Redis做缓存。根据业务容忍度来设计是关键。

别把Redis当数据库，设置过期时间

Redis是缓存,它的内存是宝贵的，一定要给你存的每一条数据设置一个合理的过期时间（TTL），哪怕设置得长一点（比如一天），也得有，否则，数据只增不减，迟早会把内存撑爆，导致Redis崩溃或者疯狂淘汰数据，性能骤降。

接入的“姿势”要优雅

在代码里,不要到处散落着操作Redis的代码，应该把它封装成一个独立的服务或者工具类，所有缓存操作都通过这个接口进行，这样以后想换缓存中间件，或者修改缓存策略，只需要改这一个地方就行了，这叫关注点分离，能让代码更干净、好维护。

总结一下

用Redis提升性能,核心思想就是“空间换时间”，接入时，把握好“旁路缓存”这个基本策略，警惕穿透、击穿、雪崩三大坑，根据业务情况处理好一致性，并时刻记得设置过期时间，它不是银弹，不能解决所有性能问题，但在应对高并发读取、减少数据库压力方面，绝对是一把趁手的好武器，用对了，项目健步如飞；用错了，反而徒增烦恼。