建站提速必备redis缓存：实战干货与踩坑总结
我去年做淘客流量站的时候，峰值十万UV压过来，MySQL直接原地躺平，五分钟连挂三次，损失小一千广告费，那滋味现在想起来还牙疼。后来用上redis缓存，同样的流量，服务器负载直接掉了70%，页面打开从两秒变两百毫秒，广告点击率都涨了两个点。redis缓存到底解决了什么核心问题
做站点的，谁都遇见过流量上来就卡的情况。为啥卡？大部分时候不是服务器带宽不够，是数据库扛不住。
你想啊，一篇十万加的爆文，一万个人同时点开，每打开一次就要去MySQL查一次文章内容，MySQL存数据在硬盘，读写速度比内存慢几百倍，扛不住这么多并发，直接排队，用户就看见转圈圈，甚至502。
缓存就是干这个的，把用户经常访问的热数据，提前放到读写速度超快的内存里，用户来要直接给，不用每次都麻烦数据库。而redis，就是现在最受欢迎的内存缓存工具，没有之一。
说实话早年我还用Memcached，后来早就全换redis了，不说别的，支持字符串、列表、哈希各种数据类型，还能持久化，大流量下稳定性甩Memcached好几条街，新手直接用redis准没错。
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/a1453102-97ec-477a-a6be-e710a7e47f6d.jpg
redis缓存对接MySQL架构图
新手玩redis缓存，最容易踩的致命坑
我踩过的坑比你吃过的米都多，挑几个最致命的说，别等出事才后悔。
第一个就是缓存击穿。什么意思？你那个爆文刚好是热点key，设置了一小时过期，刚好一小时整，几万并发同时过来，发现缓存没了，齐刷刷全去查数据库，直接把库打死。我第一次出事就是这个，刚才说的那一千多块学费，就是这么交的。
解决其实不难，真正的热点数据，比如站点首页、头部导航、百万赞爆文，直接给它设置永不过期不就行了？实在要更新，后台改完内容手动更缓存就行。或者加个互斥锁，同一时间只有一个请求去更新缓存，其他请求先拿着旧缓存用着，也不会打崩库。
第二个坑是缓存穿透。这个很多新手听都没听过，其实就是有人专门搞你，请求一堆不存在的数据，比如你是商品站，他一直请求商品id是-1、-999这种不存在的东西，缓存里肯定没有，每次都去查数据库，一来二去直接把你库打穿，你还以为是流量涨了，其实是被攻击了。我前年就遇到过这种CC攻击，拦了好久才发现问题出在缓存穿透上。
解决也简单，两种方法，一种是把不存在的请求也缓存个null，过期时间设个三五分钟，不会占用多少空间，还能挡住重复请求。另一种就是用布隆过滤器，把所有存在的key提前存在里面，不存在的直接拦掉，根本不让他碰数据库。
第三个坑是缓存雪崩，这个比前面两个更狠。我早年刚学redis的时候图省事，给所有缓存都设了3600秒过期，结果刚好3600秒到了，上万key集体过期，所有请求全砸去数据库，直接全站宕机，我喝着茶刷着手机，突然收到一堆用户私信说打不开，登服务器一看，数据库直接跑满了，重启都花了十几分钟。
那怎么防？第一，过期时间一定要加随机偏移啊，比如基础过期是3600秒，每个key再加个0到600秒的随机数，别凑一块过期。第二，redis本身要做高可用，别单节点跑，主从备份搞起来，大流量就上集群，一个节点挂了还有其他顶上，不会全凉。
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/6f4e46e6-4545-4ea2-9f0d-330b115c974f.jpg
redis缓存三大问题对比说明图
怎么用redis缓存，才够高效省成本
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/89bfb910-57f7-4c0a-ae27-459d9fbed591.jpg
怎么用redis缓存，才够高效省成本
很多新手要么不敢用，要么一股脑把所有数据都塞进去，这两种都不对。给你说几个我实战出来的经验。
第一，只放读多写少的热数据，别什么都塞。redis内存比服务器硬盘贵多了，犯不着浪费。什么该放？站点的导航栏、热门文章列表、用户头像信息、商品基础信息，这些都是大部分用户经常访问，改的又少的，放缓存收益最大。那种实时更新的评论、动态，或者一年都没人看一次的老文章，就老老实实待在数据库就行，不用凑热闹。
第二，key命名要规范，别搞大key。我见过有人把一整篇几万字的文章塞成一个redis字符串key，那不出问题才怪。redis是单线程处理命令，一个大key操作会直接卡住所有其他请求，整个redis都会变慢。所以大内容一定要拆分，key命名就用「业务名:类型:id」的格式，比如「article:hot:10086」，清晰好维护，也不容易冲突。
第三，淘汰策略选对，别用默认的错配置。很多人装完redis就不管了，默认淘汰策略都没改。如果你的redis就是专门用来做缓存的，直接选allkeys-lru就行，内存满了就自动删掉最近最少使用的key，腾空间给新数据，非常好用。如果你redis还存了一些永久不过期的冷数据，那再选volatile-lru，只淘汰带过期时间的key。
第四，持久化按需开，不用为了安全硬开AOF。如果你redis就是纯缓存用，数据丢了大不了从数据库重新拉一遍，那只开RDB持久化就够了，性能更高，还少占IO。如果redis还要存持久化数据，那再开AOF混合持久化，安全第一。
说实话，小站点做缓存，512M的redis足够用了，别听服务商瞎忽悠，上来就给你开几个G，浪费钱。流量大了再加也不迟。不过话说回来，流量涨之前一定要提前扩容，别等内存爆了才动手，那时候站点已经挂了，损失已经造成了。
现在很多云服务商都有现成的弹性redis服务，新手不用自己搭，直接买就行，省了自己搭集群搞备份的功夫，省心太多。
缓存本身的逻辑很简单，就是空间换时间。redis能火这么多年，就是够用、稳定、门槛低，新手踩过几个坑，很快就能玩明白，给站点带来的提速效果，真的立竿见影。 对新手特别友好，解释得很细致，就算零基础也能看懂大半。 楼主的经历很有参考价值，给了我很多新的思考方向，非常感谢。 不管是内容还是排版都很用心，看得出来楼主花了不少时间，必须支持。 认真看完了整篇内容，感觉受益匪浅，期待楼主后续更多优质的分享。 非常有建设性的意见，对解决实际问题有很大的参考意义。
虽然篇幅不长，但句句都是重点，简洁又有深度，非常不错。 内容干货满满，没有多余废话，对有需要的人来说帮助真的很大。 支持理性讨论，反对无脑争吵，楼主带了个很好的头。 很多点我之前都没想到，楼主一提醒才恍然大悟，收获很大。 看完很有启发，也引发了我不少思考，有空也想分享下自己的看法。 支持楼主继续更新，这么好的内容值得让更多人看到和学习。 逻辑严谨，条理分明，一看就是经过认真思考和整理的内容。 内容真实不做作，没有多余套路，都是实实在在的经验之谈。 楼主态度很认真，回复也很耐心，这样的楼主值得大家支持。 感谢楼主无私分享经验，少走了很多弯路，对我们帮助特别大。 对这个话题有了更全面的认识，不再只停留在表面理解。 这个问题困扰我很久了，看了你的帖子终于有思路了，非常感谢。
页:
[1]