9. 瞬时响应：淘宝网的架构演化案例分析
9.1淘宝网的业务发展历程
业务推动技术发展。
业务:模仿eBay 拍卖交易 -> 明码标价（一口价）
技术:php -> java, mysql->oracle
9.2 淘宝网技术架构演化
linux + apache + mysql +php（lamp）
免费，开源支撑，学习成本低java + oracle + mvc（webx） + orm（lbatis）+ weblogic + EMC
业务发展，php难维护，存储不堪重负
一个字:贵。用钱解决性能问题。其他资源集中攻坚业务发展。spring + jboss/jetty + mysql/nosql
业务成熟，商业软件解决方案性价比不高且无法适应互联网业务，
9.3小结
技术发展动力:不得已。
10. 维基百科的高性能架构设计分析
区区十几人维护一个全球流量排名前十的大型网站（2012）。
10.1wikipedia 网站整体架构
lamp架构.
原因: 非盈利尽可能使用免费资源。
- GeoDNS:域名解析，就近解析。
- LVS: 基于linux的开源负载均衡服务器。
- squid: 基于linux的开源反向代理服务器。
- lighttpd: 开源的应用服务器，比apache 更轻量快速。
- php: 免费流行的开发语言。
- memcached: 集中，分布式开源缓存系统。
- lucene: 开源全文搜索引擎。
mysql: 开源关系数据库。
一个字:便宜，免费。
10.2 wikipedia 性能优化策略
特点:巨量查询请求，业务简单。
10.2.1 wikipedia 前端性能优化
前端: 应用服务器之前的部分（dns服务，cdn服务，反向代理服务，静态资源服务等）。
80%服务可以通过前端服务返回，不需到达应用服务器。
cdn（圣杯:集中缓存热门词条） + squid（反向代理集群:缓存热门词条静态资源） + LVS （负载均衡:命不中路由到应用服务器）
缓存准则:
- 内容页不包含动态信息
- 防止缓存失效和数据不一致
- REST风格url
方便cdn快速查找，避免重复缓存 - html头写入缓存控制信息，控制内容是否缓存及有效期。
10.2.2 wikipedia 服务端性能优化
服务端运行的是核心部分，因此使用最优的硬件部署。
其它手段：
- 使用APC，这是一个php字节码缓存模块，可以加速代码执行，减少资源消耗。
- 使用imagemagick进行图片处理和转化。
- 使用tex进行文本格式化，特别是将科学公式内容转换成图片格式
- 替换php字符串查找函数strtr()，使用更优算法。
10.2.3 wikipedia 后端性能优化
后端服务：缓存、数据库、存储、应用服务器都属于后端服务。
优化手段：主要是使用缓存。
wikipedia缓存策略：
- 热点特别集中的数据缓存在应用服务器本地。
特点：数据量少、读频率高。 - 缓存数据内容尽量是最终格式：如html
静态化，减少解析 - 使用缓存服务器存储session
应用无状态
mysql优化：
- 使用大内存。
- 使用RAID0磁盘阵列。
- 使用较低数据库事务水平
加速宕机恢复，牺牲事务一致性（弱事务）。 - 双（多）机互备
- 降机写服务
11. 海量分步式存储系统Doris的高可用架构设计分析
略
12. 网购秒杀系统架构设计案例分析
12.1 秒杀活动技术挑战
- 对现有网站业务造成冲击
- 高并发下的应用、数据库负载
- 突然增加的网络及服务器带宽
- 直接下单
通过url绕过下章详情页，直接调用下单提交接口。
12.2 秒杀系统的应对策略
秒杀系统独立部署
不影响正常业务秒杀商品页静态化
直接通过缓存加载，不占用后端资源。租借秒杀活动网络带宽
应对瞬时大流量动态生成随机下单页面url
下单提交url动态生成，无法提交知道而提前下单。
12.3 秒杀系统架构设计
特点：用户更关注结果，不关注商品信息丰富程度
对策：页面尽量简洁、下单数量不可更改、使用默认收货地址（或下单成功后修改）。
其它问题：
如何控制秒杀商品页购买按钮的点亮
静态页面难以控制按钮点亮动作。
办法：静态页面引用一个动态js文件。此js文件加上动态版本号（如：页布上动态生成），不允许缓存。由此js中的逻辑控制按钮。由于此js文件很小，大量请求可以接受。如何只允许第一个提交的订单被发送到订单子系统
允许大流量进入到下单页，进行大规模拦截，不如挑选一部分进行下单页，其余的全部路由到结束页。然后对挑选的进行最终的精确处理。被动拦截不如主动挑选.
13. 大型网站典型故障案例分析
大型网站架构师最有价值的地方：不在于技术多少，而在于经历多少故障。
13.1 写日志也会引发故障
现象：磁盘空间不足。
原因：日志级别太级（debug)
经验教训：
- 应用程序日志输出配置与第三方组件日志输出分别配置。
- 日志级别至少为warn
- 关闭不恰当的第三方库的日志
13.2 高并发访问数据库引发故障
现象：数据库load太高。
原因分析：网站首页动态调用一条简单sql.
经验教训：
- 首页不应该访问数据库（缓存化、搜索引擎）
- 静态化
13.3 高并发情况下锁引发故障
现象：服务器频繁响应超时，又快速恢复。
原因分析：不恰当的加锁
经验教训：小心使用锁。
13.4 缓存引发故障
现象：未发布新应用，数据库load飙升。
原因：有人关闭了缓存服务器。
经验教训：缓存不仅是改善性能，而是网站架构不可或缺的一部分。
13.5 应用启动不同步引发故障
现象：某应用发布后，服务器立即崩溃。
原因：反向代理与应用服务器启动顺序不一致，导致应用服务器无完全启动成功，被引入大量请求，最终无法成功启动成功。
经验教训：按顺序启动。
13.6 大文件读写独占磁盘引发的故障
现象：文件上传功能缓慢。
原因：有人上传了超大文件，导致资源独产。
经验教训：按文件类型和用途分别管理，互不影响。
13.7 滥用生产环境引发的故障
现象：生产环境网络延迟非常厉害。
原因：生产环境上做压力测试
经验教训：规范生产环境的使用。
13.8 不规范的流程引发故障
现象：某应用发布，数据库load飙升。
原因分析：有人为了方便本地测试把缓存代码注释了，上线是未恢复。
经验教训：
- 代码提交要谨慎
- 加强代码review
13.9 不好的编程习惯引发的故障
现象：某应用上线新功能，有少量用户投诉无法使用。
原因分析：第一次使用功能的新用户，代码中根据历史使用记录创建对象（第一次使用没有历史记录），导致空指针。
经验教训：异常校验（如：空指针检查）
13.10 小结
架构设计尽量简单，易于应用。