目录

1. 前言
2. 架构的演化
3. 加点业务

1 前言

商品详情是一个典型的读多写少的场景，我们作为高并发读案例来分析吧

2 架构的演化

架构演化1

最初可能是生成动态生成的，如下图

tomcat直接去数据看查询数据 然后模板渲染返回给用户

这个搞法DB肯定受不了啊 然后演化成下图

架构演化2

这个架构把动态生成页面改成了，静态文件。

注意:笔者不推荐挂载

1. 其一因为挂载属于强耦合，
2. 其二 在后期运维起来相当麻烦

nginx访问静态文件的速度那是相当牛逼啊

假设一台nginx支撑1000并发

但是随着访问量增加 到了3000并发，那一台就比较吃紧了

架构演化3

架构继续演化，nginx变成了集群，这样就可以通过增加机器数量实现更高并发了

如果不考虑共享存储的磁盘IO和网络带宽确实OK

而实际上当商品数量越来越多，访问量越来越大 磁盘IO和容量必然会成为瓶颈，架构继续演化

架构演化4

1. 用redis 集群替换磁盘挂载
2. 用nginx+lua直接访问redis集群，直接读内存，速度更快了

这样的架构从技术上来讲已经能够支持非常高并发了

多数情况下能够满足用户期望

3 加点业务

技术是要服务于业务的，脱离了业务场景的技术是无根之木

业务需求来了

假如现在有1000万个页面，保存在redis集群

现在呢，产品经理想修改下模板的样式，比如过年了加点红色，清明了加点白色 等等

怎么办呢？

把1000万页面全部重新生成一遍？

需要多久？1分钟？1小时？1天？

依赖的服务接口 以及数据库能够支持如此高的并发吗？

架构又要演化了

架构演化5

我们再看一下商品详情页的生成过程

tomcat 从数据库读取元数据 然后读取模板文件合并成 详情页html

问题的关键就在这里，用户访问页面前我们就把模板给定了

所以要把模板文件前置，前置到nginx +lua

看架构图

模板文件保存在nginx+lua层，

请求进入后从redis集群读取商品数据，然后与模板合并成html

最后返回给浏览器

最后我们回顾一下支撑高并发的演化过程

1. 直接读数据库 --- 数据库存在瓶颈
2. 读静态文件挂载磁盘 --- 磁盘IO存在瓶颈
3. 读redis --- 业务不灵活
4. 读redis + 模板前置

实际上在商品详情页架构中采用了多级缓存的架构

我们以后再展开讲

ok 打完收工！