Redis缓存真厉害，网站速度飞起来了，缓存时间怎么设置才最合适？

说到Redis让网站速度飞起来，这感觉确实很棒！以前每次打开页面都要等数据库慢悠悠地查数据，唰”一下就出来了，这种提升是实实在在的，但高兴之余，那个“缓存时间怎么设置才最合适？”的问题就冒出来了，设短了，缓存老是失效，Redis的威力大打折扣；设长了，用户看到的数据可能是过时的旧闻，这就本末倒置了，这就像给食物定保质期，时间太短浪费，时间太长吃坏肚子，这个“黄金时间”没有一刀切的答案，它完全取决于你缓存的是什么样的“食物”。

咱们得摸清楚你缓存的是什么类型的数据，不同的数据，对“新鲜度”的要求是天差地别的。

第一类，变化极慢甚至不变的数据。 比如网站的城市列表、商品分类目录、用户的基本权限角色等，这类数据可能几个月甚至几年才变动一次，对于它们，Redis缓存的命中率当然是越高越好，你可以设置一个非常长的时间，比如几天、几周甚至更长，为了方便更新，一个常见的做法是设置一个很长的过期时间（例如30天），但同时提供一个后台管理功能，一旦管理员修改了这些基础数据，就立刻通过程序手动删除Redis里对应的缓存（这叫做缓存失效），这样，下次有请求时，发现缓存没了，就会自动从数据库加载最新的数据并重新缓存起来，根据像“知乎”平台上一些技术文章提到的思路,这是处理静态数据的经典模式。

第二类，变化有规律，允许短期不一致的数据。 这是最常见的情况，比如新闻网站的头条新闻、电商网站的商品详情页、用户的基本信息（昵称、头像）等，这些数据会变，但不需要实时同步到秒级，用户通常能够接受几分钟甚至几小时的延迟，你修改了昵称，稍微过一会儿其他人才看到新昵称，是完全能接受的，对于这类数据，设置缓存时间就要考虑业务容忍度和数据更新频率，可以设置几分钟到几小时不等，新闻头条可以设置10-30分钟的缓存，商品详情可以设置1-2小时的缓存，这个时间的设定，可以参考《阿里巴巴Java开发手册》这类实践指南中建议的思路，它往往建议根据业务的峰值访问量和数据变更频率来找到一个平衡点，目的是既减少数据库压力,又保证数据的相对新鲜。

第三类，变化频繁且要求很高的实时性。 最典型的例子就是商品库存、秒杀活动的计数、股票的实时价格，这类数据如果用了缓存，过期时间必须设置得非常短，比如几秒、几十秒，甚至不设置过期时间，而是采用更复杂的策略，每次数据变更时都同步更新缓存和数据库（这涉及到写操作的高可用，比较复杂），如果缓存时间设长了，可能会出现超卖（库存显示有货实际已卖光）或者显示错误价格等严重问题，在很多关于高并发系统的技术讨论中，比如一些资深工程师在“掘金”等技术社区分享的案例里，都会强调对这类强一致性要求高的数据，缓存策略要格外谨慎，简单的设置过期时间可能不够,需要结合其他机制。

除了看数据的“性子”，还得考虑你的业务场景，你运营的是一个刚上线的小网站，访问量不大，数据库完全扛得住，这时候，缓存时间设短一点也没关系，首要目标是保证数据绝对准确，但如果你做的是像“双十一”这样的促销活动，瞬时流量海啸般涌来，这时候可能就得采取一些非常规手段了，宁愿让部分用户看到稍微延迟一点的销量数据（设置一个稍长的缓存时间，比如1分钟），也要死死护住数据库不被冲垮，这时候，“性能”和“可用性”的优先级就暂时超过了“绝对的数据实时性”，这种在极端流量下的取舍策略,在一些大型互联网公司的技术复盘文章中经常被提及。

还有一个简单粗暴但有时很有效的方法——懒人法则，如果你实在拿不准，可以先设置一个相对较短的安全时间，比如5分钟或10分钟，去观察Redis的监控数据，看看缓存的命中率怎么样，如果发现命中率非常高（比如95%以上），说明缓存效果很好，大部分请求都没碰数据库，那你甚至可以适当延长缓存时间，如果命中率很低，说明缓存老是失效，可能设置的时间太短了，或者缓存键的设计有问题，通过这种“设置-观察-调整”的循环,你也能慢慢找到最适合自己业务的甜蜜点。

别忘了缓存不只是设置个时间那么简单，它是一整套策略，当缓存时间到了，Redis会自动删除数据（这叫过期淘汰），但如果内存满了，Redis还会根据你设定的策略（比如LRU，最近最少使用）来淘汰一些缓存，哪怕它还没过期，确保你的Redis实例内存大小是足够的，并且选择了合适的淘汰策略,这样才能让缓存系统稳定地为你服务。

Redis缓存时间设置是一门平衡的艺术，核心就是在“数据实时性”、“数据库压力”和“用户体验”之间找到一个最佳的平衡点，多看看你的业务数据，多做一些测试和观察，那个最合适的“魔法数字”自然会浮现出来。