持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第29天，点击查看活动详情
🍊作者简介：少年不想说话，努力长大
🍊往期回顾：从零开始Redis（十八）
🍊近期目标：写完基础源码，点赞👍🏼、收藏⭐、留言📩
现在我们说说redis在生产通常怎么弄，应用中解决的问题，毕竟前期准备工作我们都已做完；
首先用户会去访问我们的项目服务，我们的服务在运行中会向数据库请求我们的数据，这里暂不考虑数据量过大情况， 我们只考虑高并发的情况；对于涌入的大量请求如果我们不加一道拦截请求的话一下进入数据库会造成数据库瞬间爆掉也不是不可能的，怎么办，这就是redis的用处了；
我们首先将某些会经常访问到的信息存入Redis（这叫热点key），这样将大部分请求直接通过服务转移到redis服务器上（减轻了数据库的压力）就可以了；你并发越高我只需要多部署几台机器就行了，一点影响都没，
缓存击穿、穿透、雪崩
但是呢，这也带来一定问题，如果我设定的热点key请求打到上面的很少，进而还是去请求数据库，这个时候我们得思考下是不是我们的热点key设置的问题了， 或者是不是有人故意而为之呢？这个时候我们可以监控这些操作并记录分析，进而将redis性能最大化，这个得现场一步一步验证；
如果我设置了过期时间，那么我数据过期了咋办，这时会继续将请求打到数据库上； 我们可以这么做，就是查库后赋值，并且在查库时加锁，一次只许一个去查（防止多个请求打过去），查到直接返回并塞入redis中， 可是如果我数据库当时也没有数据，这样的话就会不停请求数据库不停返回null，怎么办，我们可以直接塞入null字符串，在返回的时候解析下即可， 这就是缓存穿透/击穿的一点思路，待到我们数据库有数据时可以手动刷到redis中或者等待该key过期自动刷入（这个查询塞值的过程中如果报错，代表我们可能正在加载数据，等待一会再重新reload）；
对于缓存雪崩，就是同时有多个key失效，会造成不同请求直接打进redis，如果过期key过多的话直接插依然不好，因为大量请求打进来会阻塞，会增加我们的服务压力，所以我们可以在请求入口处加限制，免得请求都打进来还没有返回，还不如直接返回更好点，在失效key时间上随机一点，免得同时失效；
对于缓存这方面只能说需要不停上生产，试错，遇到问题多了，就熟悉了。不遇几个问题谁能长大；好啦🥗🥗🥗；
结束结束，那就🛴🛴🛴
如果对你有所帮助
点个赞呗
