Redis缓存用来提升数据表性能的一个实操分享，聊聊怎么用redis加速查询和减少数据库压力

这个实操分享的想法,最初是从我们一个挺头疼的项目里来的，当时我们有个用户中心的查询，就是最普通的那种，根据用户ID查用户昵称、头像这些基本信息，平时没啥问题，但一到搞活动，用户量一上来，数据库服务器就有点顶不住了，CPU经常飙到90%以上，页面打开变得特别慢，我们用的就是最普通的MySQL数据库。

最开始的想法就是加机器,升级数据库配置，但这都是要花大钱的，后来我们技术负责人就说，试试用Redis做个缓存吧，花小钱办大事，Redis你可以把它理解成一个超级快的临时仓库，它把数据都存在内存里，所以读写的速度比存在硬盘上的MySQL要快上百倍都不止。

那我们具体是怎么做的呢？思路其实特别直接，原来用户的请求是直接砸到数据库上的，现在我们想，在数据库前面，挡一个Redis。

第一步,定个规矩，我们决定，当需要查询某个用户信息的时候，程序不能直接去查数据库了，得先跑去Redis这个临时仓库里看看，有没有我们要的数据，我们在Redis里，给每个用户数据起一个唯一的钥匙，比如叫做 user:info:123，这个123就是用户的ID。

第二步,设计存取流程，当一个查询请求过来，比如要查用户123的信息：

1. 程序首先拿着钥匙 user:info:123 去Redis里找。
2. 如果找到了,太棒了！我们称之为“缓存命中”，那就直接把Redis里的数据返回给用户，整个过程完全不用麻烦数据库，速度飞快。
3. 如果没找到,我们称之为“缓存未命中”，那没办法，程序只能老老实实去数据库里查。
4. 从数据库里查出用户123的数据后,做两件事：第一件，返回给用户；第二件，也是更重要的一件，就是把这个数据用那把钥匙 user:info:123 存到Redis里，这样，下一个再来查同一个用户的人，就能直接从Redis里拿到了。

这个过程就像是在数据库前面安排了一个反应极快的前台,常见的问题它都能直接回答，只有它回答不了的新问题，才需要去问后面的数据库专家。

光这样还不够,会遇到新问题，最大的问题就是，数据要是变了怎么办？比如用户123自己修改了昵称，如果数据库里的昵称更新了，但Redis里存的还是旧的，那之后所有查询都会读到错误的旧数据，这就叫“数据不一致”。

为了解决这个问题,我们引入了第三步：更新策略，我们定了另一个规矩：以后只要有更新用户信息的操作，比如修改昵称、头像，在成功更新了数据库之后，必须做一件事：把Redis里对应的那把钥匙的数据删掉，这个操作叫“删除缓存”，这样做的结果是，下一个来查询这个用户的请求，在Redis里就找不到数据了（缓存未命中），它就会去数据库里取出最新的数据，然后重新把新数据塞回Redis里，这样就保证了用户最终读到的是新数据。

虽然在某些极短暂的时刻（比如刚删完缓存，还没来得及有新查询把新数据加载进来的时候），可能还会有一次旧的查询读到旧数据，但对于我们这种对实时性要求不是百分百苛刻的场景，是完全能接受的，这个策略简单有效，不容易出问题。

那数据一直放在Redis里,会不会把内存撑爆？这就是第四步：设置过期时间，我们在把用户数据存进Redis的时候，会同时设置一个有效期，比如24小时，意思是，就算这个用户数据期间一直没人修改，24小时之后，Redis也会自动把它清理掉，这有两个好处：一是防止不活跃的用户数据长期占用内存；二是作为一种兜底策略，即使有某种极端情况导致缓存没被及时清除，它最终也会过期，然后下次查询时重新从数据库加载正确数据。

用了这套方案之后,效果是立竿见影的，最直观的就是数据库的压力下来了，活动期间CPU从90%多降到了30%左右，用户的查询响应速度也快了很多，因为大部分请求根本就没到数据库那一层，在Redis这就被处理掉了。

这不是说Redis是万能的,它只适合放一些经常被读取、但不经常修改的热点数据，像一些实时要求非常高，或者需要复杂关联查询的场景，还得靠数据库，但对我们这种简单的键值查询，Redis真是个神器，这次实操给我们的最大启发就是，解决性能问题不一定非要硬扛着升级硬件，有时候换个思路，用合适的工具做合适的事，性价比要高得多。