Redis用来做页面静态化其实挺有意思，速度快还省资源，能不能更好地优化体验呢？

Redis用来做页面静态化确实挺有意思，速度快还省资源，这点很多开发者都深有体会，比如在一些技术社区像知乎或者CSDN上，经常能看到大家讨论这个方案，它的核心思路很简单：就是把那些不经常变动、但生成起来又比较耗时的页面（比如商品详情页、新闻文章页），提前生成好完整的HTML代码，然后像存小零食一样，塞进Redis这个高速的内存数据库里，下次再有用户来访问这个页面，就不用劳烦后端的应用服务器和数据库再去拼凑数据了，直接从Redis里取出HTML，闪电般地甩给用户的浏览器，这比每次都要查数据库、渲染模板快太多了，而且极大地减轻了后端服务器的压力,非常省资源。

就像你问的，能不能更好地优化体验呢？当然能，如果只是简单地存和取，那只能算是个基础用法，要想让用户体验更上一层楼,我们可以在一些细节上动动脑筋。

一个关键问题是缓存什么时候更新？ 如果你设置一个固定的过期时间，比如10分钟，那可能会遇到两种情况都不太好的情况：要么是页面内容其实已经变了（比如文章有错别字被小编修改了），但用户看到的还是10分钟前的旧页面，体验不好；要么是页面内容根本就没变，但10分钟一到，缓存失效了，下一个用户又得重新生成一次,造成了不必要的资源消耗。

那怎么优化呢？一个更聪明的办法是采用主动失效的策略，简单说，就是别傻等缓存自己过期，而是在数据发生变化的时候，主动去更新缓存，在内容管理系统（CMS）里，当管理员点击“发布”或“更新”一篇文章时，除了正常更新数据库，后台程序可以立刻发出一条命令，把Redis里存放的这篇旧文章的静态页面缓存删掉（或者直接更新为新的版本），这样，下一个用户来访问时，发现缓存没了，就会触发系统重新生成一个最新的页面并存回Redis，这种做法能保证用户几乎总是看到最新的内容，延迟极低，这种思路在开源项目或者一些大厂的技术博客中经常被提及,是一种很常见的优化手段。

我们可以考虑缓存颗粒度的问题，最开始我们说的是缓存整个页面，这固然很快，但如果页面中只有一小部分会变化呢？比如一个网站的页头页尾是通用的，只有中间主体内容变化，或者更细一点，一个页面上除了文章正文，还有一个“热门文章推荐”的侧边栏，文章正文可能一天不变，但热门文章列表可能每小时都在变，如果你把整个页面缓存一小时,那热门文章就失去实时性了。

这时候，我们可以玩点“拼图”游戏，也就是局部静态化或者叫片段缓存，我们不缓存整个大页面了,而是把页面拆成几个独立的模块。

1. 文章正文模块（缓存时间可以设长点，比如一天，或者用上面说的主动失效策略）。
2. 热门文章列表模块（缓存时间设短点，比如10分钟）。
3. 用户个人登录信息模块（可能根本不能缓存）。

当用户请求页面时，后端程序可以同时去Redis里获取这几个模块的缓存，如果某个模块的缓存还在，就直接用；如果过期了，就重新生成这个小块的内容，最后再把几个模块像拼积木一样组装成最终的HTML页面，这样，既保证了大部分内容的高速输出，又让那些需要频繁更新的小块内容保持了一定的灵活性，这种做法在追求极致性能的Web框架（如Django、Ruby on Rails）的文档中都有详细阐述。

再来，我们还可以关心一下缓存未命中的用户体验，什么是缓存未命中？就是当第一个用户访问一个还没有生成过静态缓存的页面时，Redis里是空的，这时候系统不得不去数据库查数据、渲染模板，这个过程可能会比较慢，这个用户就会感觉到明显的延迟,这对于第一个用户来说体验就不太好。

为了解决这个“冷启动”问题，可以尝试预热缓存，就是在低峰期（比如半夜），通过一个脚本，模拟用户访问，提前把那些预计访问量会很大的热门页面生成好静态缓存，并塞进Redis里，这样等第二天高峰来临，大部分用户都能直接命中缓存，享受飞一样的速度，很多电商网站在大促前夜,都会做这种缓存预热操作。

虽然Redis是内存存储速度极快，但内存资源毕竟比硬盘贵，为了更省资源，可以给不同的页面设置不同的缓存生存时间，比如首页、热门文章页，访问量大，TTL（生存时间）可以设短一点，保证新鲜度，而一些归档的老文章页，访问量小且内容几乎不变，TTL可以设得非常长，甚至不设置过期时间，只有当内容被修改时才被动清除,这样能更精细地利用宝贵的内存空间。

用Redis做页面静态化，入门很容易，但要想做得精，更好地优化用户体验，就需要我们在缓存策略、更新机制、颗粒度控制和预热等方面多下功夫，这些优化思路在很多技术实践分享中都能找到影子，核心目标就是在保证内容尽可能实时性的前提下，最大限度地发挥Redis的速度优势,同时合理地节约每一分计算和存储资源。