自动化生成的页面直接塞进Redis，省时又方便，缓存瞬间搞定

开始）

我之前听一个做电商的朋友抱怨,说每次大促销，他们的网站页面就卡得不行，尤其是那个商品详情页，访问量一大，数据库就撑不住了，页面加载慢得像蜗牛，用户等不及就直接关掉了，损失了好多订单，他们技术团队想了好多办法，什么数据库优化、加服务器，效果都不明显，而且成本蹭蹭往上涨，后来他们用了了一个听起来特别简单粗暴的办法，就是把整个生成好的页面直接塞进Redis里，结果效果出奇的好，以前让人头疼的页面加载问题，一下子就解决了。

这个办法说白了,偷懒”但高效，平常我们访问一个网页，比如那个商品页，服务器每次都要忙活半天：先去数据库里把商品的文字、价格、图片地址查出来，然后把这些信息像拼积木一样，按照网页的模板组装成一个完整的HTML页面，最后再把这个页面发给我们的浏览器，这个过程每次都要重复，尤其是一个热门商品，一秒钟有成千上万人点进去，服务器就得重复成千上万次同样的劳动，不累趴下才怪。

而那个直接塞进Redis的方法,就跳过了中间所有这些繁琐的步骤，它的思路是这样的：既然这个商品页面内容又不是每分钟都变（比如价格和库存可能会变，但描述、图片啥的一般很稳定），那何必每次都要临时拼凑呢？我们提前把这个页面完整地生成好，不就得了？他们就在后台搞了个小工具，当商品信息更新后，或者定期地，自动运行一下，这个小工具的工作就是模拟一次页面访问，把最终展示给用户看的那个完整的、带着所有HTML代码的页面，整个儿保存下来，变成一个长长的字符串。

那这个长长的字符串存哪儿呢？就存到Redis里面，Redis这东西，你可以把它理解成一个放在内存里的、速度超级快的超级大字典，每个商品都有个唯一的编号吧，比如商品ID是12345，那好，他们就在Redis这个“大字典”里，建立一个键值对，键（Key）就是像 “page:product:12345” 这样的一个字符串，值（Value）就是刚才生成好的那个完整的HTML页面内容，存到Redis里的数据，因为是在内存里，所以读取速度极快，比去硬盘上的数据库里查数据要快上百倍千倍。

这样一来,当用户再来访问商品12345的页面时，服务器就不用再去劳烦数据库了，它只需要做一件极其简单的事情：拿着“page:product:12345”这个钥匙，直接去Redis这个高速仓库里，把对应的那个现成的HTML页面取出来，几乎不用做任何处理，直接把这个完整的页面扔给用户的浏览器就行了，这个过程简单到就像是从身边的文件柜里直接拿出一份已经打印好的文件递给别人，而不是现场去翻资料、打字、排版、打印。

我朋友说,这么一改，效果立竿见影，最直观的就是页面打开速度，以前可能要一两秒甚至更久，现在几乎是秒开，用户体验好了不是一星半点，服务器的压力大大减轻，因为绝大部分的访问压力都被Redis扛住了，数据库那边清闲得很，再也不用担心被流量冲垮了，他们甚至可以用更少、更便宜的服务器来支撑同样甚至更高的流量，省下了一大笔钱，对于技术团队来说，也省心多了，不用整天提心吊胆地盯着数据库指标看了。

这个方法也不是说一点问题都没有,最大的问题就是“缓存更新”，商品管理员突然修改了这个商品的价格或者库存，或者搞活动加了张优惠券，那Redis里存的那个老页面就过时了，显示的还是旧信息，这肯定不行，他们就得有个机制，一旦后台有商品信息变更，就立刻触发一次那个自动生成页面工具，把新的页面重新生成一遍，然后赶紧把Redis里旧的那个页面覆盖掉，这叫保证数据的一致性，如果他们忘了这个步骤，或者更新不及时，那用户看到的就是错误的信息，会出大乱子。

就是存储空间的问题,Redis虽然是内存数据库，速度快，但内存毕竟比硬盘贵，如果网站上有几十万、几百万个商品，每个商品的页面都存一份完整的HTML，那占用的内存空间也是不小的，这就需要做一些权衡和规划，比如可能只对访问量最大的热门商品做这种全页面缓存，那些冷门的商品还是用老办法动态生成，或者定期清理那些很久没人访问的页面缓存，腾出空间给新的热门商品。

不过总的来说,对我朋友他们那个电商网站来说，利远远大于弊，这种“把整个页面塞进Redis”的做法，在技术圈里好像有个专门的说法，但我更愿意叫它“傻瓜式”缓存法，因为它原理简单，实现起来也不复杂，但对于解决高并发下的页面性能问题，效果却是杠杠的，这让我想起一句话，有时候最有效的解决方案，并不一定是最复杂、最高科技的，反而是那种直击问题本质的、简单直接的方法，他们就是抓住了“页面内容变化不频繁”和“Redis读取速度极快”这两个关键点，一结合，就把一个老大难问题给化解了，所以后来我跟别的做网站的朋友聊天，遇到类似的性能瓶颈，我都会建议他们不妨试试这个“偷懒”的法子，说不定有奇效。 结束）