高并发高可用复杂系统中的缓存架构(二) 大型网站架构
小型电商网站的商品详情页的页面静态化架构以及其缺陷
背景是商品详情页的系统架构，以此基础讲解 -> 缓存架构 -> 高并发 -> 高可用
电商网站里，大概可以说分成两种，
-
小型电商，简单的一种架构方案，页面静态化的方案；
-
大型电商，复杂的一套架构
为了讲解大型电商的详情页架构，这里先把小型的讲解下
部分页面静态化或全量的页面静态化
先来看看页面静态化带来的问题，假设有一个商品详情页的模板如下
<html>
<title></title>
<body>
商品名称：#{productName}
商品价格：#{productPrice}
商品描述：#{productDesc}
</body>
</html>
里面的占位语法需要数据来填充，比如保存在 mysql 中的，此时数据变化了或者模板变化了，都需要重新渲染成 html 页面，放在 nginx 上，供用户访问。如果只是某一个商品数据变化了只影响了一个页面那还好说，直接重新渲染这一个即可，但是有商品推荐的，可能其他商品详情页面里面也会出现。这个时候就比较难判定了，可能只会全量渲染了
那么问题来了，对于小网站，页面很少，很实用，非常简单，使用的模板引擎有 velocity、freemarker 等，页面数据管理的 cms 系统，内容管理系统等做一个一键全量渲染功能即可
对于大型网站来说，比如淘宝，他们的商品数据太多了，根本就没有这么多的时间去重新渲染，上亿的商品等，可能需要好几天
大型电商网站的异步多级缓存构建 + nginx 数据本地化动态渲染的架构
大型电商网站的详情页架构一般是这样的核心思路，如上图
两个关键点：
-
缓存数据生产服务
-
nginx 上的 html 模板 + 本地缓存数据
来捋一捋流程：
-
用户访问 nginx
会先从 nginx 的本地缓存获取数据渲染后返回，这个速度很快，因为全是内存操作。 本地缓存数据是有时间的，比如 10 分钟
-
假如 nginx 本地缓存失效
会从 redis 中获取数据回来并缓存上
-
假如 redis 中的数据失效
会从缓存数据生产服务中获取数据并缓存上
-
缓存数据生产服务
本地也有一个缓存，比如用的是 ehcache 他们通过队列监听商品修改等事件，让自己的缓存数据及时更新
-
其他服务
商品、店铺等服务能获取到商品的修改事件等，及时往 mq 中发出商品的修改事件， 并提供商品原始数据的查询。这里可能是直接从 mysql 库中查询的
这样一来，在缓存上其实就挡掉了很多数据，一层一层的挡并发