读书_大型网站技术架构03_李智慧

第九章

9 淘宝网的架构演化案例分析

9.1 淘宝网的业务发展历程

9.2 淘宝网技术架构演化

2003年LAMP
LAMP(linxu,apache,mysql,php)，当时web最火的是php（自己当时还用过，现在呢？php还有人用么？至少web领域企业用户很少了吧），最火的php教程是兄弟连的thinkphp教程。

2004年java+oracle
mvc采用自研框架webx

后续
mysql,nosql等取代oracle
很多框架工具也采用自研（有钱，任性）

9.3 小结

10 维基百科的高性能架构设计分析

10.1 Wikipedia网站整体架构

目前也是LAMP
这个是挺出乎意料的，但也够牛的，现在还在坚守lamp

1
2
3
4
5
6
7
8

GeoDNS：基于开源域名服务器软件 BIND（Berkeley Internet Name Domain）的增强版本，可将域名解析到离用户最近的服务器。
LVS：基于 Linux 的开源负载均衡服务器。
Squid：基于 Linux 的开源反向代理服务器。
Lighttpd：开源的应用服务器，较主流的 Apache 服务器更轻量、更快速。实践中，有许多网站使用 Lighttpd 作为图片服务器。
PHP：免费的 Web 应用程序开发语言，最流行的网站建设语言。
Memcached：无中心高性能的开源分布式缓存系统，稳定、可靠、历久弥新，是网站分布式缓存服务必备的。
Lucene：由 Apache 出品，Java 开发的开源全文搜索引擎。
MySQL：开源的关系数据库管理系统。

10.2 Wikipedia性能优化策略

10.2.1 Wikipedia前端性能优化

Wikipedia CDN 缓存的几条准则为：
内容页面不包含动态信息，以免页面内容缓存失效或者包含过时信息。
每个内容页面有唯一的 REST 风格的 URL，以便 CDN 快速查找并避免重复缓存。
在HTML 响应头写入缓存控制信息，通过应用控制内容是否缓存及缓存有效期等。

10.2.2 Wikipedia服务端性能优化

Wikipedia 还使用许多其他开源组件对应层进行如下优化。

1
2
3
4

使用 APC，这是一个 PHP 字节码缓存模块，可以加速代码执行减少资源消耗。
使用 Imagemagick 进行图片处理和转化。
使用 Tex 进行文本格式化，特别是将科学公式内容转化成图片格式。
替换 PHP 的字符串查找函数 strtr()，使用更优化的算法重构。

10.2.3 Wikipedia后端性能优化

后端优化最主要的手段是使用缓存，将热点数据缓存在分布式缓存系统的内存中，加速应用服务器的数据读操作速度，减轻存储和数据库服务器的负载。Wikipedia 的缓存使用策略如下：
热点特别集中的数据直接缓存到应用服务器的本地内存中，因为要占用应用服务器的内存且每台服务器都需要重复缓存这些数据，因此这些数据量很小，但是读取频率极高。
缓存数据的内容尽量是应用服务器可以直接使用的格式，比如 HTML 格式，以减少应用服务器从缓存中获取数据后解析构造数据的代价。
使用缓存服务器存储 session 对象。
相比数据库，Memcached 的持久化连接非常廉价，如有需要就创建一个 Memcached 连接。

作为存储核心资产的 MySQL 数据库，Wikipedia 也做了如下优化：
使用较大的服务器内存。在 Wikipedia 应用场景中，增加内存比增加其他资源更能改善 MySQL 性能。
使用RAID0 磁盘阵列以加速磁盘访问，RAID0 虽然加速磁盘访问，但是却降低了数据库持久可靠性（一块盘坏了，整个数据库的数据都不完整了）。显然 Wikipedia 认为性能问题迫在眉睫，而数据可靠性问题可以通过其他手段解决（如 MySQL 主从复制，数据一步备份等）。
将数据库事务一致性设置在较低水平，加快系统恢复速度。
如果 Master 数据库死机，立即将应用切换到 Slave 数据库，同时关闭数据写服务，这意味着关闭词条编辑功能。Wikipedia 通过约束业务获得更大的技术方案选择余地，很多时候业务后退一小步，技术就可以前进一大步。

11 海量分布式存储系统Doris的高可用架构设计分析(略)

Doris（https://github.com/itisaid/Doris）是一个海量分布式KV存储系统，其设计目标是支持中等规模高可用、可伸缩的KV存储集群。跟主流的NoSQL系统HBase相比（Doris0.1 vs. HBase0.90），Doris具有相似的性能和线性伸缩能力，并具有更好的可用性及更友好的图形用户管理界面。
对于一个数据存储系统而言，高可用意味着两个意思：
高可用的服务：任何时候，包括宕机、硬盘损坏、系统升级、停机维护、集群扩容等各种情况，都可以对系统进行读写访问操作。
高可靠的数据：任何情况下，数据可靠存储，不丢失。
那么高可用的架构设计也就是在各种软硬件故障的情况下，系统如何保障数据可靠存储，服务可用。

12 网购秒杀系统架构设计案例分析

12.1 秒杀活动的技术挑战

1. 对现有网站业务造成冲击：活动时间短、并发访问量大，如果和网站原有应用部署在一起，必然对现有业务冲击。
2. 高并发下的应用、数据库负载：秒杀开始前，用户不断刷新浏览器页面保证不错过，请求如果按一般网站应用架构，会对应用服务器、数据库服务器造成极大负载。
3. 突然增加的网络及服务器带宽：假设秒杀页面大小200KB（主要是商品图片），那么所需带宽是200KB×10000=2GB。
4. 直接下单：秒杀开始前，只能浏览，不允许下单。

   12.2 秒杀系统的应对策略

   1．秒杀系统独立部署
   2．秒杀商品页面静态化
   3．租借秒杀活动网络带宽
   4．动态生成随机下单页面URL

   12.3 秒杀系统架构设计

1．如何控制秒杀商品页面购买按钮的点亮
使用JavaScript脚本控制（越小越好），在秒杀商品静态页面中加入一个JavaScript文件引用，该JavaScript文件中加入秒杀是否开始的标志和下单页面URL的随机数参数，当秒杀开始的时候生成一个新的JavaScript文件并被用户浏览器加载，控制秒杀商品页面的展示。这个JavaScript文件使用随机版本号，并且不被浏览器、CDN和反向代理服务器缓存。如图12.3所示。

2．如何只允许第一个提交的订单被发送到订单子系统
由于最终能够成功提交订单的用户只有一个，为了减轻下单页面服务器的负载压力，可以控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接进入秒杀结束页面。假设下单服务器集群有10台服务器，每台服务器只接受最多10个下单请求，如图12.4所示。

秒杀系统的整体架构如图12.5所示。

12.4 小结

13 大型网站典型故障案例分析

13.1 写日志也会引发故障

日志级别过低，日志过多。个人经验来看，一般服务器（云服务）都会配置监控，一旦cpu，磁盘或网络出现异常都会有告警短信。 所以说这个经验应该是过时的物理机时代的经验了。

13.2 高并发访问数据库引发的故障

13.3 高并发情况下锁引发的故障 185

13.4 缓存引发的故障 185

13.5 应用启动不同步引发的故障 186

13.6 大文件读写独占磁盘引发的故障 186

13.7 滥用生产环境引发的故障 187

13.8 不规范的流程引发的故障 187

13.9 不好的编程习惯引发的故障 188

13.10 小结 188

参考

http://reader.epubee.com/books/mobile/40/409fcdb63d3ad585ec579058873917da/text00021.html

架构设计和高并发系列
读书_大型网站技术架构01_李智慧
读书_大型网站技术架构02_李智慧
读书_大型网站技术架构03_李智慧
读书_高并发设计40问之一基础
读书_高并发设计40问之二数据库
读书_高并发设计40问之三缓存
读书_高并发设计40问之四消息队列
读书_高并发设计40问之五分布式服务
读书_w3c架构师01通用设计与方法论
读书_w3c架构师02典型架构实践
读书_w3c架构师03数据库与缓存
分布式事务
高并发之缓存
高并发之降级
高并发之限流
数据库_读写分离
消息队列_01消息队列入门
消息队列_02rabbitMQ入门
消息队列_03rabbitMQ安装和使用