高并发高可用复杂系统中的缓存架构(二) 大型网站架构
小型电商网站的商品详情页的页面静态化架构以及其缺陷
背景是商品详情页的系统架构,以此基础讲解 -> 缓存架构 -> 高并发 -> 高可用
电商网站里,大概可以说分成两种,
-
小型电商,简单的一种架构方案,页面静态化的方案;
-
大型电商,复杂的一套架构
为了讲解大型电商的详情页架构,这里先把小型的讲解下
部分页面静态化或全量的页面静态化
先来看看页面静态化带来的问题,假设有一个商品详情页的模板如下
<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 库中查询的
这样一来,在缓存上其实就挡掉了很多数据,一层一层的挡并发