18.1 淘宝大浏览量商品详情系统简介
HTTP请求经过负载均衡设备分配到某个域名对应的集群，经过Nginx代理到JBoss或者Tomcat容器，由他们负责具体处理用户请求。目前这些大浏览量的系统大部分需要读取的数据都已经直接走
K/V 缓存了，不会直接从DB获取数据。
18.2 系统面临哪些挑战
突发的流量冲击； 攻击和恶意请求；
18.3 淘宝前台系统的优化历程
系统拆分，静态文件合并，前段页面异步优化和JSON化
去DB依赖、引入缓存、提升单机的QPS，关注用户体验。
Velocity， BIgPipe
静态化改造
统一cache, CDN化， 网络协议
18.4 大浏览量系统的静态改造
18.4.1 什么是静态化系统
- URL能唯一标识一个页面
- 页面中不包含与浏览者相关的因素
- 页面中不包含时间因素，页面的DOM不能随时间而变化。
- 页面不包含地域因素
- 不能包含cookie等私有因素。
18.4.2 为什么要进行静态化架构设计
在web层可以直接返回结果，不用到达系统后端。
静态化优点：
改变了缓存方式：直接缓存HTTP连接而不仅仅缓存数据，WEB代理服务器根据请求URL直接取出对应的HTTP响应头和响应体直接返回，这个响应连HTTP都不用重新组装，同样，HTTP请求头也不一定需要解析，所以获取数据最快。
改变了缓存的地方：不是在JAVA层面做缓存，而是直接在web服务器层上做，而web服务器（如Nginx， ）都擅长处理大并发的静态文件请求。
18.4.3 如何改造动态系统
如何将动态页面改造成适合缓存的静态页面呢？改造方法就是前面说的去掉那几个影响因素。解决办法就是将这些因素单独分离出来，也就是动静分离。
动静分离：
URL唯一化，detail页面就可以通过商品ID来唯一标识一个URL .
分离与浏览者相关的因素。登录信息可以单独拆分出来，通过动态请求获取。
分离时间因素。服务器输出的时间也通过动态请求获取。
异步化地域因素。把detail系统上与地域相关的做成异步方式来获取。
去掉Cookie。
动态内容结构化：
分离出动态内容后，如何组织这些内容页很关键，这些动态内容会被页面中的其他模块用到，例如判断该用户是否登录、用户ID等。将这些信息JSON化可以方便前端获取，
如何组装动态内容：
知道如何分离那些内容后，又如何组织呢？现在的问题时如何获取它们，并和静态文件组装在一起。获取动态内容有两种方式：ESI和CSI
ESI：
CSI：
18.4.4 几种静态化方案的设计以及选择
一致性hash:
方案一： Niginx + Cache + java
方案二：
方案三：
18.4.5 如何解决失效问题
被动失效：处理时效性不敏感的数据，采用设置Cache时间长度这种自动失效的方式，同时也要开发一个后台管理界面，手动失效。
主动失效：
Cache失效中心监控数据库表变化，发送purge失效请求；
装修时间戳比较失效装修内容；
JAVA系统发布，请求Cache
VM模板发布，清空Cache;
18.4.6 服务端静态化方案的演进：CDN化
将Cache前移到CDN上，因为CDN离用户最近。但是有几个问题：
失效问题：CDN分布全国，要在秒级时间内失效这么广泛的Cache，对CDN的失效系统要求很高。
命中率问题：命中率是Cache的重要指标，Cache分散，命中率降低。
发布更新问题：
解决失效问题：
解决命中率问题：