在本文中，您将会了解到关于大型网站技术架构笔记的新资讯，同时我们还将为您解释大型网站技术架构pdf的相关在本文中，我们将带你探索大型网站技术架构笔记的奥秘，分析大型网站技术架构pdf的特点，并给出一些
在本文中，您将会了解到关于大型网站技术架构 笔记的新资讯，同时我们还将为您解释大型网站技术架构pdf的相关在本文中，我们将带你探索大型网站技术架构 笔记的奥秘，分析大型网站技术架构pdf的特点，并给出一些关于<大型网站技术架构：核心原理及案例分析>笔记-->伸缩性架构、BAT架构师分享之：大型网站技术架构、《大型网站技术架构——核心原理与案例分析》第1章：大型网站架构演化、《大型网站技术架构》网站的高性能架构及优化的实用技巧。
本文目录一览：- 大型网站技术架构 笔记（大型网站技术架构pdf）
- <大型网站技术架构：核心原理及案例分析>笔记-->伸缩性架构
- BAT架构师分享之：大型网站技术架构
- 《大型网站技术架构——核心原理与案例分析》第1章：大型网站架构演化
- 《大型网站技术架构》网站的高性能架构及优化
大型网站技术架构 笔记（大型网站技术架构pdf）
大型网站架构演化
特点：
高并发、大流量
高可用
海量数据
用户分布广泛、网络情况复杂
安全环境恶劣
需求快速变更、发布频繁
渐进式开发
演化发展历程
数据量的总大小 一个机器放不下
数据的索引（B+ Tree）一个机器的内存放不下
访问量（读写混合）一个实例不能承受
只有当以上3件事情任何一件或多件满足时，我们才需要考虑往下一级演变。
1. 初始阶段：
应用程序、数据库、文件都在一台服务器，如常用的Linux+PHP+Apache+Mysql
2. 应用服务和数据库分离
原因：性能变差、存储空间不足
三台服务器：应用服务器（运算能力：CPU）、文件服务器（更大的存储）和数据库服务器（更大的存储和内存）
3. 使用缓存改善
原因：数据库访问压力太大； 数据访问遵循2-8定律
将访问多的20%的数据放在缓存上，可分为应用服务器端的本地缓存和分布式的远端缓存
4. 应用服务器集群
原因：单一服务器处理的请求链接成为瓶颈
使用应用服务器集群，使用反向代理实现负载均衡、可用性监测、可伸缩的实现
5. 数据库读写分离
原因：使用缓存后，仍有部分读操作和全部写操作要访问数据库，随着规模的增大，这些操作造成数据库瓶颈
数据库进行主从备份和读写分离
6. 使用反向代理和CDN加速网站响应
原因：加速网站访问速度
CDN: 部署到客户端最近的网络提供商的机房，用户可从自己最近的网络提供商获取数据，多用于静态内容如CSS、图片等
反向代理：一般代理都是在客户的浏览器端，而此处的代理是在网站端。 用户请求先通过反向代理，反向代理如果缓存有用户需要的资源则立刻返回，否则调用相应服务器
7. 使用分布式文件系统
原因：业务需求继续增大
8. 使用分布式数据库
分库：
分表：单表数据规模非常庞大时
9. 使用NoSQL和搜索引擎
特点：数据存储和检索越来越复杂
NoSQL对可伸缩的分布式特性有很好的支持
10. 业务拆分
将网站拆分成多个应用，每个应用独立维护
11. 分布式服务
将共有业务（用户管理、商品管理等）提取出来独立部署，上层业务复用这些业务完成具体操作
大型网站架构模式
网站架构模式
分层
将系统分成MVC层，对C进一步分成service层和Dao层
注意：定义好层次边界和接口
作用：便于合作开发和维护；方便分离部署
分割
对业务进行拆分，彼此之间低耦合，然后部署到单独的应用服务器上
分布式
分层和分割的主要目的就是为了切分后的模块便于分布式部署
常用方案有：
1. 分布式应用与服务：改善性能和复用
2. 分布式静态资源：如JS，CSS独立部署并有独立的域名
3. 分布式数据和存储：对传统数据库使用分布式、采用NoSQL
4. 分布式计算：MapReduce
集群
在多个机器上部署单一模块，提供扩展性、有效性、负载均衡的处理
缓存
条件：某些数据被频繁访问；数据在某个时间段内有效，不会很快过期
有以下方式：
CDN：离用户最近，静态资源
反向代理：网站的前段，静态资源等
本地缓存：应用服务器本机
分布式缓存
异步
使用消息队列实现，单一应用服务器使用多线程之间的消息队列实现异步；分布式环境中使用分布式的消息队列实现异步
好处：降低耦合；加快响应速度；消除并发访问高峰
冗余
实现7*24小时服务，提高可用性
服务器集群实现； 数据库的冷、热备份
自动化
发布过程：自动化代码管理、自动化测试、自动化部署、自动化安全检测
运行过程：自动化监控、自动化报警、自动化失效转移和回复、自动化降级
安全
身份认证： 密码和手机校验码
加密：登录、交易和存储的敏感数据
验证码：机器人程序攻击网站
编码转换：XSS攻击和Sql注入
过滤：垃圾信息和敏感信息
风险控制： 对交易转账等重要操作根据交易模式和交易信息进行
大型网站核心架构要素
性能
定义：用户访问的快慢
评价指标：响应时间，TPS，系统性能计数器
手段：
1. 浏览器端：页面压缩、浏览器缓存、合理布局页面、减少cookie传输、CDN、CSS放在上面和js放在最下边
2. 应用服务器端：反向代理服务器、缓存、异步请求、集群
3. 代码层：多线程、改善内存管理
4. 数据库端：索引、缓存、SQL优化、主从备份和读写分离、NoSQL数据库
可用性
定义：可以访问的时间
评价指标：几个9，如99.99%
手段：
1. 冗余（应用服务器集群、数据库备份）
2. 软件质量：预发布验证、自动化测试、自动化发布、灰度发布
伸缩性
定义：通过向集群中加入服务器提高并发访问和数据存储需求
评价指标：是否容易添加新的服务器；新的服务器能否提供无差别服务；服务器数量是否有限制
手段：
1. 应用服务器集群：服务器上不保存数据（无状态）+合适的负载均衡设备
2. 缓存集群：改进缓存路由算法：hash环
3. 数据库集群：路由分区将部署有多个数据库的服务器组成一个集群； NoSQL数据库天生比较好
扩展性
定义：快速响应需求变化
评价指标：增加新业务，是否对现有产品透明无影响
手段：
1. 事件驱动：消息队列实现
2. 分布式服务：业务通过分布式框架调用可复用服务
安全性
定义：现存和潜在攻击手段的应对策略
瞬时响应：网站的高性能架构
网站性能测试
1. 不同视角的网站性能
1）用户视角
浏览器和服务器通信时间+处理时间+浏览器解析响应数据的时间
2）开发人员视角
应用程序本身和子系统的性能，有 响应时间、吞吐量、并发处理能力、系统稳定性等指标
3）运维人员视角
关注基础设施性能和资源利用率，如网络带宽利用率和服务器资源利用率等
手段：建设优化骨干网、定制的服务器、使用虚拟化技术优化资源利用率
2. 性能测试指标
响应时间：
执行一个操作需要的时间
测量方法：重复请求，如一个请求重复执行1万次，求得单次平均访问时间
并发数：
同时访问的请求数量
测量方法：模拟并发用户，在两次请求之间加入随机等待时间（思考时间）
吞吐量：
单位时间内处理的请求数量，TPS（每秒事务数）
并发小：吞吐量增加、响应时间小幅上升；并发逐渐增加：吞吐量下降、响应时间快速上升；并发达到崩溃点：吞吐量为0，不响应
性能计数器
描述服务器和操作系统性能的数据指标，如System Load（进程数和CPU数）、内存和CPU使用、对象与线程数
3. 性能测试方法
性能测试：以系统规划初期的指标测试
负载测试：增加并发请求，直到多项性能指标达到临界值
压力测试：直到系统崩溃
稳定性测试：特定软硬件条件下，给系统加载一定业务压力，使系统运行一段时间
4. 性能优化策略
性能分析： 检查各环节日志——》检查监控数据，关注内存、磁盘、网络、CPU——》确定是代码问题、架构设计还是系统资源不足
Web前段性能优化
浏览器访问优化
1. 减少http请求
合并javascript css、图片（如果每张独有不同的超链接，可通过css偏移响应鼠标点击操作，构造不同的URL）。
2. 使用浏览器缓存
设置http头中的Cache-Control和Expires设定浏览器缓存
静态文件变化后：改变js文件名并更新html文件中的引用
更新静态资源时，采用批量更新的方法，比如更新10个图标文件，应一个文件一个文件逐步更新，并有一定时间间隔
3. 启用压缩
可对html css javaScript启动GZip压缩，但会对服务器产生压力
需要在 通信和服务器资源间权衡考虑
4. CSS放在页面最上面，JavaScript放在最下面
浏览器会在下载完全部CSS后才进行页面渲染，最好是把CSS放在页面上边
浏览器在加载Js后立刻执行，有可能阻塞整个页面，因此js放在下面，但如果页面解析时就要用到JavaScript的，放在下面就不太合适了
5. 减少cookie传输
静态资源使用独立域名，避免发送cookie
哪些数据需要写入cookie要慎重考虑
CDN加速
用于对静态资源的代理
反向代理
部署在应用服务器前边，实现 安全过滤、缓存加速web请求、负载均衡
应用服务器性能优化
主要手段有缓存、集群和异步
分布式缓存
网站优化第一定律：优先考虑缓存优化
缓存实际是内存的hash表
1. 合理使用缓存：
1）频繁修改的数据：读写比在2:1以上
2）没有热点的访问
3）数据不一致和脏读：设置失效时间、数据更新时立即更新缓存
4）缓存可用性
5）缓存预热：新缓存上没数据
6）缓存穿透：持续高并发地请求某个不存在的数据，会对数据库造成很大压力
2. 分布式缓存架构
集群
异步
使用消息队列：减少响应延迟、平滑并发访问波动；
需要对返回状态做特殊处理，如订单提交（等待消费者处理完后才显示成功）等
代码优化
1. 多线程
使用原因：IO阻塞会释放CPU； 多CPU每个对应一个
多少线程： 启动线程数=【任务执行时间/(任务执行时间-IO等待时间)】*CPU数
线程安全问题：对象是无状态的；使用threadLocal 方法内对象；并发访问资源时加锁
2. 资源复用
开销很大的资源，如数据库连接、网络连接、线程、复杂对象。有两种模式：单例和对象池
3. 数据结构
字符串Hash散列算法：Time33算法： hash(i)=hash(i-1)*33+str[i]
相似的字符串hash值区别很大： MD5算法
4. 垃圾回收
有助于程序优化和参数调优，分为stack和heap，堆空间分为Young Generation（Eden from to）和Old Generation，新建对象在Eden，当Eden满时，复制到from；Eden又满了，将Eden和from——》to，下次Eden+to——》from，young都满了就放到old，如果都满了就触发Full GC（时间比较长）
合理设置young 和 old大小，尽量减少Full GC
存储性能优化
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
万无一失：网站的高可用性架构
可用性的度量和考核
可用性度量： 几个9，如99.99%
可用性考核（对工程师的考核）： 故障时间*故障权重
高可用的网站架构
企业级采用昂贵的软硬件，如IOE；互联网更多是PC级服务器、开源的数据库和操作系统
主要手段：数据和服务的冗余备份和失效转移。
高可用的应用
1. 无状态应用服务器
采用负载均衡软件，一般都提供：心跳检测可用性；失效转移、负载均衡
2. 有状态的应用服务器
1）session复制：当服务器集群规模下的时候可用。通过开启web容器的session复制功能，让每台服务器上都有用户session信息。 应用在集群规模小的情况下。
2）session绑定：使用负载均衡软件的源地址hash算法，保证同一IP的处理总在一台服务器上。但使用较少，主要是可用性的问题，如果该机器done了，该用户的session会丢失
3）cookie记录session：1）cookie大小限制；2）每次都要传输；3）关闭cookie访问不正常；4）简单易用；5）支持应用服务器的线性伸缩。 大部分网站或多或少使用。
4）session服务器： 可用性高，伸缩性好，性能也不错，信息大小又没限制。 将服务器中session都放到独立的session服务器统一管理，每次读写session时，都通过session服务器。通过对分布式缓存、数据库基础上包装实现。
高可用的服务
1. 分级管理： 对不同的功能模块进行分级，对于高优先级使用好的硬件，更快的相应速度；等访问量大时，可关闭低优先级功能
2. 超时设置： 设置调用的超时时间，当服务不可用或超时后，通信框架报出异常，根据调度策略转移到其他服务器
3. 异步调用：消息队列
4. 服务降级：访问高峰期，拒绝低优先级服务
5. 冥等性设计：请求重新发送时，保证统一请求重复调用和一次调用结果相同，比如转账（使用交易编号）
高可用的数据
1. 冷备： 廉价； 不能保证数据一致性；可用来定期备份
2. 异步热备：只写成功一份，其他之间复制
3. 同步热备：同时向多个副本中写入
4. 失效转移：失效确认（心跳检测和访问异常）——》访问转移——》数据恢复
5. 库表散列： 不同业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。
高可用网站的软件质量保证
1. 网站发布
每次关闭服务器集群中的一小部分，发布完后立刻可以访问。
使用发布脚本实现
2. 自动化测试
Selenium 自动化测试技术
3. 预发布验证
4. 代码控制
要求：发布版本和开发版本互不影响
主干开发、分支发布：发布时主干出一个branch，如果该版本有bug，在分支上修改发布，并将修改merge回主干
5. 自动化发布
6. 灰度发布
每天只发布一部分服务器，观察运行稳定没有故障
网站运行监控
1. 数据采集
用户行为日志收集：服务器端（web服务器）、客户端（javascript）
性能监控
运行数据报告
统计：基于实时计算框架Storm的日志统计和分析工具
2. 监控管理
系统报警
主动失效转移
自动优雅降级
永无止境：网站的伸缩架构
伸缩性：当访问量增加时，通过增加资源（服务器）可以提高吞吐率
伸缩性设计是复杂的、没有通用的、完美的解决方案
网站架构
根据功能进行物理分离实现伸缩
一台服务器——》数据库分离——》缓存分离——》静态资源从应用服务器分离
纵向分离（按层分割）：网络具体产品--可复用业务服务--基础技术服务--数据库
横向分离（业务分割）：网站前台--买家前台--卖家后台
单一功能通过集群实现伸缩
条件：当随着访问量增大，即使分离到最小粒度的独立部署，单一服务器也不能满足需要
应用服务器集群
1. 如果是无状态的，可以使用负载均衡（请求分发，服务器可用性监测）
2. 负载均衡实现技术有：
1. http重定向： 使用http request将用户请求重新定向到处理服务器，优点是简单；缺点是两次请求才能完成一次访问，性能较差。重定向服务器可能成为系统瓶颈。 http302会被搜索引擎判定为作弊。 实际使用中不多见
2. dns域名解析：在DNS中实现负载均衡。优点是负载均衡给了DNS实现简单。可以解析到用户最近的服务器地址；缺点是当下线了某台服务器不能立即反应。 实际中大型网站使用DNS作为第一级负载均衡，到同样提供负载均衡的内部服务器
3. 反向代理： 反向代理服务器提供缓存资源、负载均衡的功能，需要部署双网卡和双ip，优点是 和反向代理功能一起部署比较简单。缺点是反向代理服务器是所有请求和响应的中转站，性能可能成为瓶颈
4. IP负载均衡：负载均衡服务器修改数据包中的目的IP地址实现。优点较反向代理有更好的处理性能；缺点是所有请求都经过，数据吞吐量受限于网卡带宽
5. 数据链路层负载均衡：修改mac地址实现。使用最广，linux平台使用LVS(Linux Virtual Server)
3. 负载均衡算法
轮询：请求依次分发
加权轮询：根据服务器的硬件情况加权
随机：好的随机数本身就很均衡，如果硬件配置不同，可使用加权随机
最少链接：记录每个服务器的连接数，新的请求分配到最少的
源地址散列：对IP进行散列，使得该IP的上下文信息存储在这台服务器上，实现会话粘滞
分布式缓存
1. 目标： 新加入的缓存使得已缓存的数据尽可能能被访问到
2. memchached 分布式缓存集群，其中路由算法很重要：
1. 余数hash： 缓存数据hashcode/服务器数目。 但添加新的缓存服务器就麻烦了，解决方案是 使用虚拟节点的一致性hash环
数据存储服务器
1. 目标：相对于缓存，对数据的持久性（能存到硬盘）和可用性（能访问到数据）要求更高
2. 关系型数据库
数据库复制： 主从读写分离； 分库（不同表在不同数据库集群，缺点是不能进行跨库join）； 分表（产品有Amoeba和Cobar，Cobar可与mysql集群使用）
伸缩的实现：Corba的服务器使用负载均衡；Mysql（Cobar利用Mysql的数据同步功能进行数据迁移）
无法执行跨库Join和事务
避免事务或利用事务补偿机制（分布式事务）代替数据库事务；分解数据访问逻辑避免JOIN操作
支持JOIN的，如GreenPlum，但延迟比较大
3. NoSql数据库
Apache 的HBase，依赖于可分裂的HRegion（数据块）和HDFS（分布式文件系统）。使用者无需处理
随需应变：网站的可扩展架构
扩展性： 对现有系统影响最小情况下，可以加功能，符合开闭原则
构建可扩展的网站架构
软件架构师最大的价值不是掌握多少先进技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包括横向模块和纵向模块。这种能力是专业的技术和经验，对业务场景的理解，对人性的把握。
核心思想是模块化，并在此基础上，降低模块间的耦合性
主要手段是分层和分割，模块间通过分布式消息队列和分布式服务聚合
利用分布式消息队列降低耦合性
事件驱动架构
借助事件完成模块间合作，常见的是生产者消费者模式，最常用的分布式消息队列
好处是：更好的响应延迟；平缓高峰压力；
分布式消息队列
ActiveMQ：除了实现分布式消息队列，在伸缩性（加入队列服务器）和可用性（内存队列满后，写入磁盘）也做了改善。
避免系统当机造成消息丢失，会把发送成功的消息存储在生产者服务器，等消息被消费者处理后才删除消息。
分布式服务
纵向拆分：将一个大应用拆分为多个小应用，部署为单独的web系统
横向拆分：将复用业务拆分后部署为分布式服务，新增业务调用这些服务
纵向比较简单，通过梳理业务将较少相关的业务剥离，使其成为独立的web应用。横向不仅要识别可复用的业务，设计服务接口，规范依赖关系，还需要一个完善的分布式服务管理框架。
web service与企业级分布式服务
可整合异构系统和构件分布式系统
缺点： 臃肿的注册和发现机制；低效的xml序列化；开销相对较高的HTTP远程通信；复杂的部署和维护手段。
大型网站分布式服务的需求
服务注册和发现
服务调用
负载均衡：对热门服务如登录或商品服务，需要部署在集群上
失效转移
高效的远程通信
整合异构系统
对应用最少侵入：尽量使框架和业务独立
版本管理：提供者升级接口发布新版本服务，并同时提供旧版本服务，当请求者调用接口升级后才关闭旧版本服务。
分布式服务框架设计
开源的阿里的Dubbo
描述：
1. 消费者通过服务接口调用服务，服务接口通过代理加载服务，代理调用服务框架客户端模块，客户端包括服务提供者列表、负载均衡、失效迁移服务
2. 提供者提供服务管理容器注册服务
3. 支持多种通信协议和序列化协议，使用NIO通信框架，具有较高的网络通信性能
可扩展数据结构
无需修改表字段就可以新增字段，使用NoSql数据库
利用开放平台建立生态圈
提供更多的增值服务，将API开放被第三方开发者使用
固若金汤：网站的安全架构
网站应用攻击和防御
1. XSS攻击
跨站点脚本攻击，有两种，一种是反射性（在url中 ?<script src... >），一种是持久型XSS（将恶意脚本的请求保存到数据库中，常用语论坛和博客）
防范手段： 消毒（对提交的文本进行匹配替换，如<img src= 对<进行转义)； HttpOnly（防止xss窃取cookie，即浏览器禁止页面Javascript访问带有HttpOnly的cookie）
2. 注入攻击
需要对数据库有所了解，通过开源（网站使用开源软件搭建）；错误回显（从错误信息猜测表结构）；盲注（猜测数据库表结构）
防范手段：消毒（可能注入的sql，如drop table delete from等）；参数绑定（PrepareStatement， ？而不是链接字符串）
3. CSRF攻击
跨站点请求伪造：通过跨站请求，以合法用户身份进行非法操作
关键是识别请求者身份，防范手段：
表单token、
验证码（糟糕的用户体验，只在必要时使用，如支付交易）；
Referer check（检查http请求头的referer的请求来源，可用来实现图片防盗链）
4. 其他攻击和漏洞
Error code：获得异常信息，查找系统漏洞； 防范手段：专门的错误页面
html注释： 发布前自动扫描，去除html注释
文件上传：防范手段：设置上传文件白名单，只允许上传可靠的文件类型；修改文件名；使用专门的存储
路径遍历：在url中使用相对路径；防范手段：动态参数不包括文件路径信息；其他文件不适用静态URL访问
5. web应用防火墙
处理网站攻击的产品，开源的Web应用防火墙：ModSecurity
6. 网站安全漏洞扫描
根据内置规则，构造具有攻击性的URL请求模拟黑客攻击行为
信息加密技术和秘钥安全管理
1. 单向散列加密
不能逆转得到明文，字符串微小差别输出差别很大，不同长度输入得到固定长度的输出
常用的有MD5 SHA
用于密码加密保存、生成信息摘要
2. 对称加密
算法简单，效率高，系统开销少，适合对大量数据加密；使用同一秘钥，远程通信下如何安全交换秘钥是个难题
常用的有DES RC
用于信息需要安全交换或存储的场合，如Cookie加密、通信加密等
3. 非对称加密
用于信息安全传输、数字签名。
在实际中，常会混合使用对称加密和非对称加密。先使用非对称对秘钥进行安全传输，再使用对称进行信息加密和交换。 有时对一个数据两次使用非对称加密，可同时实现信息安全传输与数字签名的目的。
4. 秘钥安全管理
写到配置文件，线上和线下使用不同的
加密算法放在应用系统中，秘钥放在一个独立的服务器，甚至做成一个专用的硬件设施
秘钥分片后存储在多个服务器
信息过滤和反垃圾
1. 文本匹配
敏感词过滤： 正则表达式（敏感词较少、提交的文本长度较短）；Trie树（敏感词较多、提交的文本长，如双数组Trie算法）；多级Hash表（Trie中相同父节点的字放在Hash表中， 速度较快，浪费部分内存）
2. 分类算法
数据挖掘：分类算法， 贝叶斯算法
3. 黑名单
hash表，布隆过滤器
电子商务风险控制
1. 风险
2. 风控
规则引擎： 将业务规则和规则处理分开，业务规则可配置
统计模型：数据挖掘分类算法（当规则增加，出现规则冲突、难以维护时）
维基百科高性能架构
目标：业务简单，大部分是读操作
组成部分
GeoDNS：将域名解析到离用户最近的服务器
LVS：Linux的开源负载均衡服务器
Squid：Linux的开源反向代理服务器
Lighttpd: 开源的应用服务器，更快速，更轻量，许多网站作为图片服务器
性能优化策略
1. 前端优化
请求先经过GeoDNS到达地理最近的CDN服务器，如果没找到调用LVS到Squid服务器，如果缓存有则返回，否则通过LVS分发到Apache应用服务器集群。
2. 服务端优化
代码和数据结构（非特定）
3. 数据端优化
最主要手段是缓存，策略如下
1. 热点特别集中的数据缓存到应用服务器的本地缓存
2. 缓存数据尽可能是直接可用格式，如HTML格式
3. 使用缓存服务器存储session对象
4. 数据库如下优化
1. 更大内存
2. Master当机，关闭写功能，将应用切换到Slave
秒杀系统架构案例
技术挑战
1. 对原有业务形成冲击
2. 高并发下数据库、应用负载
3. 突然增大的服务器和网络带宽
4. 防止秒杀前下单
应对策略
1. 独立部署
和原有业务部署在不同服务器，防止高并发拖垮整个网站
2. 页面静态化
将商品详情、描述静态化到页面
3. 租借秒杀网络带宽
向运营商租借带宽
4. 动态生成随机下单页面URL
无法在秒杀前访问下单页面的URL：加入服务器端生成的随机数作为参数，在秒杀开始前才能得到
架构设计
1. 控制秒杀购买页面的点亮
秒杀商品页面加入一个javascript引用，该javascript中加入秒杀是否开始的标志和下单页面URL的随机数参数，该javascript使用随机版本号，不可被浏览器缓存
当秒杀开始时，生成一个新的javascript文件并被用户浏览器加载
2. 允许第一个订单提交
控制进入下单页面入口，只有先提交的少数用户可进入，后边的用户直接进入秒杀结束页面
架构师领导艺术
架构师角色
架构设计、软件开发
承担一些管理职能：规划产品路线、估算人力资源和时间资源
安排人员职责分工，确定计划里程碑点、指导工程师工作、过程风险评估与控制
与组内外各种角色沟通
架构师职场攻略
新员工tip
首先要做的是融入团队，和大家打成一片。等熟悉情况后，知道了水的深浅，再寻找突破口，择机而动
新员工最不需要做的就是证明自己的能力
提出问题，寻求支持
对于问题，找到谁需要对可能发生的问题负责。要解决方案被接受，就必须找到问题负责者并愿意支持他的人
提出问题tip
1. 把我的问题表述成我们的问题
2. 给上司提封闭式问题，给下属提开放式问题
给上司提问题是希望得到支持，给下属提问题是为了启发他思考
3. 指出问题而不是批评人
在合作中出现问题，告诉问题存在和紧迫性
4. 用赞同方式提出问题
我非常赞同你的方案，不过我有一个小小的建议
解决问题tip
1. 在解决我的问题前，先解决你的问题
在帮别人解决问题的过程中，熟悉了情况，解决自己的问题就得心应手了
2. 适当的逃避问题
对于不怎么靠谱的问题和方案： 这个idea很好，改天组织个会议好好讨论下
<大型网站技术架构：核心原理及案例分析>笔记-->伸缩性架构
六.伸缩性架构
1.应用服务器集群的伸缩性设计
HTTP请求分发装置->负载均衡服务器
a.负载均衡基础技术：
{HTTP重定向负载均衡}：优点比较简单，缺点性能较差（需要两次请求），使整个集群的伸缩规模有限，使用HTTP302响应码重定向，可能是搜索引擎判断为SEO作弊，降低搜索排名。
{DNS域名解析负载均衡}：优点减少负载均衡服务器维护操作，缺点没有控制权，缓存A记录，无法及时生效。常用方法：DNS域名解析到负载均衡服务器。
{反向代理负载均衡}:优点与反向代理服务器集成，部署简单。缺点性能可能成为瓶颈。
{IP负载均衡}：较反向代理负载均衡有更好的处理性能，但数据吞吐量受制于负载均衡服务器网卡带宽。
{数据链路层负载均衡（直接路由方式（DR））}：使用三角传输模式的链路层负载均衡使用最广泛。在LINUX上常用的有LVS(Linux Virtual Server)
b.负载均衡算法
{轮询Round Robin}:适用于所有服务器硬件都相同的场景
{加权轮询Weighted Round Robin}
{随机Random}
{最少连接Least Connections}
{源地址散列Source Hashing}
2.分布式缓存集群的伸缩性设计
a.Memcached分布式缓存集群的访问模型
b.分布式缓存的一致性Hash算法（一致性Hash算法+虚拟节点）
3.数据存储服务器集群的伸缩性设计
a.关系数据库集群的伸缩性设计
支持数据分片的分布式关系数据库产品：Amoeba,Cobar
{Cobar}:一个分布式关系数据库访问代理
b.NoSQL数据库的伸缩性设计
{HBase}：HRegion,HDFS,HMaster,HRegionServer
BAT架构师分享之：大型网站技术架构
早期的网站为了节省成本一般会设计成集中式系统，应用程序、数据库等都部署在一台服务器上。 但随着业务的快速度发展，逐渐出现瓶颈，按一定原则**（应用拆分、服务拆分、数据拆分、应用解耦）**，向分布式系统转型，涉及到以下环节改造。
主要环节
- 业务拆分：将整个网站业务拆分成不同的应用，每个应用独立部署维护，应用之间通过RPC或消息队列通信。
- 集群化（应用服务器；基于RPC的微服务应用等）
- LVS负载均衡，负责将请求转发给不同业务集群
- 反向代理服务器，常用的如Nginx
- 应用服务器，servlet容器，如tomcat
- 应用和数据服务分离，分别部署在不同的服务器
- 后端应用合理分层，通常分为表现层或网关层、业务逻辑层、数据持久层
- 缓存。分为两种：本地缓存；分布式缓存
- CDN化。静态内容部署到CDN，就近获取，加速网站响应。
- 数据库读写分离。数据库采用主从热备，应用服务器在写数据时访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。
- 分库分表，引入分布式数据框架
- 引入NoSQL，支持海量数据存储
- 借助elastics search等开源搜索引擎
- 异步化，系统解耦。
- 缩短业务流程，加快网站访问速度
- 消除并发访问高峰
架构五要素：
- 高性能
- 可用性(Availability)
- 伸缩性(Scalability)
- 扩展性(Extensibility)
- 安全性
1、高性能
性能的测试指标主要有：
- 响应时间：指应用执行一个操作需要的时间
- 并发数：指系统能够同时处理请求的数目
- QPS：指单位时间内系统处理的请求量
- 系统性能计数器：描述服务器或者操作系统性能的一些数据指标
性能优化，根据网站分层架构，可以分为三大类：
- Web 前端性能优化
- 减少 http 请求
- 使用浏览器缓存
- 启用压缩
- CSS 放在页面最上面，JavaScript 放在页面最下面
- 减少 Cookie 传输
- 应用服务器性能优化：主要手段有 缓存、集群、异步
- 多线程(设计为无状态，使用局部对象，并发访问资源使用锁)
- 资源复用(单例，对象池)
- 数据结构
- 异步操作(消息队列，削峰作用)
- 多台应用服务器组成一个集群共同对外服务，提高整体处理能力。
- 使用 CDN，将网站静态内容分发至离用户最近的网络服务商机房，使用户通过最短访问路径获取数据。可以在网站机房部署反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力
- 应用服务器端，可以使用服务器本地缓存和分布式缓存(网站性能优化第一定律：优化考虑使用缓存优化性能)
- 代码层面，也可以通过使用多线程、改善内存管理等手段优化性能。
- 数据库服务器端，索引、缓存、SQL 优化等性能优化手段
- NoSQL 数据库通过优化数据模型、存储结构、伸缩特性等
- 存储服务器性能优化
- 机械硬盘 vs. 固态硬盘
- B+ 树 vs. LSM 树
- RAID vs. HDFS
2、高可用
高可用的网站架构：目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问，主要手段数据和服务的冗余备份及失效转移
- 高可用的应用：显著特点是应用的无状态性
- 通过负载均衡进行无状态服务的失效转移
- 应用服务器集群的 Session 管理
- 高可用的服务：无状态的服务，可使用类似负载均衡的失效转移策略，此外还有如下策略
- 超时设置
- 异步调用
- 服务降级
- 限流
- 高可用的数据：主要手段是数据备份和失效转移机制
- 失效确认
- 访问转移
- 数据恢复
- 冷备：缺点是不能保证数据最终一致和数据可用性
- 热备：分为异步热备和同步热备
- 数据一致性(Consisitency)
- 数据可用性(Availibility)
- 分区耐受性(Partition Tolerance)
- CAP 原理
- 数据备份
- 软件质量保证
- 自动化测试
- 预发布验证
- 灰度发布
- 网站实时监控
- 警报系统
- 自动优雅降级
- 用户行为日志采集（服务器端和客户端）
- 服务器性能监控
- 监控数据采集
- 监控管理
3、伸缩性
大型网站需要面对大量用户的高并发访问和存储海量数据，不可能只用一台服务器就处理全部用户请求，存储全部数据。网站通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。
对于应用服务器集群，只要服务器上不保存数据，所有服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。
对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。虽然缓存的数据可以通过数据库重新预热，但是如果应用已经严重依赖缓存，可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。
关系数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。
至于大部分 NoSQL 数据库产品，由于其先天就是为海量数据而生，因此其对伸缩性的支持通常都非常好，可以做到在较少运维参与的情况下实现集群规模的线性伸缩。
概括起来伸缩性的分为如下几个方面：
- 应用服务器集群的伸缩性设计
- 轮询(Round Robin, RR)
- 加权轮询(Weighted Round Robin, WRR)
- 随机(Random)
- 最少链接(Least Connections)
- 源地址散列(Source Hashing)
- DNS 域名解析负载均衡
- 反向代理负载均衡(在 HTTP 协议层面，应用层负载均衡)
- IP 负载均衡(在内核进程完成数据分发)
- 数据链路层负载均衡(数据链路层修改 mac 地址，三角传输模式，LVS)
- 分布式缓存集群的伸缩性设计
- Memcached 客户端（包括 API，路由算法，服务器列表，通信模块）
- Memcached 服务器集群
- 分布式缓存的一致性 Hash 算法(一致性 Hash 环，虚拟层)
- 数据存储服务集群的伸缩性设计
- 关系数据库集群的伸缩性设计
- NoSQL 数据库的伸缩性设计
4、可扩展
系统架构设计层面的“开闭原则”，构建可扩展的网站架构
- 利用分布式消息队列降低耦合性
- 分布式消息队列
- 事件驱动架构(Event Driven Architecture)
- 利用分布式服务打造可复用的业务平台
- 分布式服务框架设计(Thrift，Dubbo)
- 可扩展的数据结构(如 HBase的 ColumnFamily 设计)
- 利用开放平台建设网站生态圈
5、网站的安全架构
XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段，此外还包括 CSRF,Session 劫持等手段。
- 攻击与防御
- Error Code
- 表单 Token
- 验证码
- jsonp请求的，Referer 校验
- SQL 注入
- html 危险字符转义
- XSS 攻击：跨站点脚本攻击（Cross Site Script）
对js转义，使其失去执行功能，只作为纯字符串展示
- CSRF 攻击：跨站点请求伪造（Cross Site Request Forgery）
防范：httpOnly;增加token校验;通过Referer识别。
- 网站安全漏洞扫描
《大型网站技术架构——核心原理与案例分析》第1章：大型网站架构演化
架构演进面临的挑战及解决思路
——来自《10分钟搞懂互联网系统演进规律：支撑亿级用户的架构都是这样来的！》
互联网主要面对的技术挑战，用一句话概括：就是用户不断上升产生的并发访问压力以及数据存储压力，所以系统需要更强的处理能力才能解决这些问题。
而系统处理能力提升，主要有两种途径：
1.垂直伸缩：
提升单台服务器的处理能力，比如用更快频率的cpu，用更多核的cpu，用更大的内存，用更快的网卡，用更多的磁盘组成一台服务器，使单台服务器的处理能力得到提升，通过这种手段提升系统的处理能力。
缺点如下：
a.当垂直伸缩达到一定程度以后，继续增加计算需要花费更多的钱。
b.垂直伸缩是有物理极限的，即使是大型机，也有自己的物理极限，它不可能无限地伸缩下去的。
c.操作系统的设计或者应用程序的设计制约着垂直伸缩，最多只能达到一个点无法继续提高。
在大型互联网出现之前，传统的软件，比如银行、电信这些企业的软件系统，主要是使用垂直伸缩这种手段实现系统能力提升的，在服务器上增强，提升服务器的硬件水平。当某种类型的服务器能力提升到了瓶颈以后，就会用更强大的服务器，比如说从服务器升级到小型机，从小型机提升到中型机，从中型机提升到大型机，服务器越来越强大，处理能力越来越强大，当然价格也越来越昂贵，运维越来越复杂。
2.水平伸缩：
单机的处理能力并不提升，也不使用更昂贵的更快的更厉害的硬件，而是通过更多的服务器，将这些服务器构成一个分布式集群，通过这个集群，统一对外提供服务，以此来提高系统整体的处理能力。
水平伸缩优点：
a.只要架构合理，能够添加服务器到集群中，你的系统就是永远可以正常运行。
b.它没有极限，它的成本也不会说到了某个临界点就突然增加。而且逐渐的增加服务器，获得相同的计算处理能力，只会比以前的服务器更便宜，不会更贵，因为硬件的价格总是在不断地下降的。
c.应用程序运行在一个服务器上，是为单一服务器而设计的，而增加服务器的话只是让程序部署在更多的服务器上，所以也不需要对应用程序进行太多的改变，应用程序不会受到硬件制约。
在互联网行业中多采用水平伸缩的手段。
一、大型网站软件系统的特点
- 高并发、大流量：PV量巨大
- 高可用：系统7*24小时不间断服务
- 海量数据：文件数目巨大
- 用户分布广泛，网络情况复杂：运营商网络难互通
- 安全环境恶劣：黑客攻击
- 需求快速变更，发布频繁：快速适应市场，满足用户需求
- 渐进式发展：慢慢地运营出大型互联网站
二、大型网站架构演化发展历程
2.1、初始阶段的网站架构
应用程序、数据库、文件等所有的资源都集中在一台服务器上，典型案例：基于LAMP架构的PHP网站。
如果用户访问量越来越多，会导致性能越来越差，数据存储空间不足。
2.2、应用服务和数据服务分离
随着业务发展，单台服务器不再满足需求，将应用和数据分离后成三台服务器（应用服务器、文件服务器和数据库服务器）。应用服务器需要处理大量的业务，因此需要更快更强大的CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的磁盘和更大的内存；文件服务器需要存储大量用户上传的文件，因此需要更大的硬盘。
当用户访问巨大，会导致数据库压力太大，访问延迟，影响网站性能，用户体验差。
2.3、使用缓存改善网站性能
网站访问特点80%的业务访问集中在20%的数据上，因此可以通过使用缓存的方式，减少数据库的访问压力，提高网站的数据访问速度。缓存分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存访问速度快，但缓存数据量有限；远程分布式缓存可以使用集群方式，容量不受限制。
单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器会成为整个网站的瓶颈。
2.4、使用应用服务器集群改善网站的并发处理能力
使用集群是网站解决高并发、海量数据问题的常用手段。改善系统性能，从而实现系统的可伸缩性。通过负载均衡调度服务器，可以将用户的访问请求分发到集群中的任何一台服务器上，使应用服务器的负载压力不再成为网站的瓶颈。
2.5、数据库读写分离
网站在使用缓存后，绝大部分数据读操作访问都可以不通过数据库就能完成，但仍有一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
大部分主流数据库都提供主从热备功能，通过配置两台数据库主从关系，将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。
2.6、使用反向代理和CDN加速网站响应
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。
使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
2.7、使用分布式文件系统和分布式数据库系统
随着网站业务的发展，两台数据库服务器仍然无法满足需求，文件系统也一样。分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。
2.8、使用NoSQL和搜索引擎
随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系型数据库技术如NoSQL和非数据库查询技术如搜索引擎。NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
2.9、业务拆分
通过分而治之的手段将整个网站业务分成不同的产品线，如淘宝将首页、商铺、订单、卖家、买家等拆分成不同的产品线，分归不同的业务团队负责。各个应用之间可以通过建立一个超链接建立关系，也可以通过消息队列进行数据分发。
2.10、分布式服务
既然每一个应用系统都需要执行许多相通的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。
三、大型网站架构演化的价值观
3.1、大型网站架构技术的核心价值是随网站所需灵活应对
大型网站架构技术的核心价值不是从无到有搭建一个大型网站，而是能够伴随小型网站业务的渐进发展，慢慢地演化成一个大型网站。
3.2、驱动大型网站架构技术发展的主要力量是网站的业务发展
业务成就了技术，事业成就了人，而不是相反。
四、网站架构设计误区
4.1、一味追随大公司的解决方案
大公司的经验和成功模块值得学习借鉴，但不能盲从。
4.2、为了技术而技术
技术是为业务而存在的，除此毫无意义。
4.3、企图用技术解决所有问题
技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。比如12306真正的问题其实不在于它的技术架构，而在于它的业务架构。
《大型网站技术架构》网站的高性能架构及优化
一、网站性能测试
（1）性能测试指标：①响应时间；②并发数；③吞吐量；④性能计数器；
（2）性能测试方法：①性能测试；②负载测试；③压力测试；④稳定性测试；
（3）性能优化策略：
①性能分析：检查请求处理各个环节的日志，分析哪个环节响应时间不合理，检查监控数据分析影响性能的因素；
②性能优化：Web前端优化，应用服务器优化，存储服务器优化；
二、Web前端性能优化
（1）浏览器访问优化：
①减少http请求：因为http是无状态的，每次请求的开销都比较昂贵（需要建立通信链路、进行数据传输，而服务器端对于每个http请求都需要启动独立的线程去处理）；减少http的主要手段是合并CSS、合并JS、合并图片（CSS精灵，利用偏移定位image）；
②使用浏览器缓存：设置http头中Cache-Control和Expires属性；
③启用压缩：可以对html、css、js文件启用Gzip压缩，可以达到较高的压缩效率，但是压缩会对服务器及浏览器产生一定的压力；
④CSS放页面最上面，JS放页面最下面：浏览器会在下载完全部CSS之后才开始对整个页面进行渲染，因此最好将CSS放在页面最上面；而浏览器在加载JS后会立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此最好将JS放在页面最下面；
⑤减少Cookie传输：一方面，太大的Cookie会严重影响数据传输；另一方面，对于某些静态资源的访问（如CSS、JS等）发送Cookie没有意义；
（2）CDN加速：
CDN（内容分发网络）仍然是一个缓存，它将数据缓存在离用户最近的地方，便于用户以最快速度获取数据。即所谓的“网络访问第一跳”，如下图所示：
CDN只将访问频度很高的热点内容（例如：图片、视频、CSS、JS脚本等访问频度很高的内容）进行缓存，可以极大地加快用户访问速度，减少数据中心负载。
（3）反向代理：
反向代理服务器位于网站机房，代理网站Web服务器接收Http请求，对请求进行转发，如下图所示：
反向代理服务器具有以下功能：
①保护网站安全：任何来自Internet的请求都必须先经过代理服务器；
②通过配置缓存功能加速Web请求：减轻真实Web服务器的负载压力；
③实现负载均衡：均衡地分发请求，平衡集群中各个服务器的负载压力；
三、应用服务器性能优化
（1）分布式缓存：
PS：网站性能优化第一定律：优先考虑使用缓存优化性能。缓存是指将数据存储在相对较高访问速度的存储介质中（如内存），以供系统进行快速处理响应用户请求。
①缓存本质是一个内存Hash表，数据以(Key,Value)形式存储在内存中。
②缓存主要用来存放那些读写比很高、很少变化的数据，如商品的类目信息、热门商品信息等。这样，应用程序读取数据时，先到缓存中取，如缓存中没有或失效，再到数据库中取出，重新写入缓存以供下一次访问。因此，可以很好地改善系统性能，提高数据读取速度，降低存储访问压力。
③分布式缓存架构：一方面是以以JBoss Cache为代表的互相通信派；另一方面是以Memcached为代表的互不通信派；
JBoss Cache需要将缓存信息同步到集群中的所有机器，代价比较大；而Memcached采用一种集中式的缓存集群管理，缓存与应用分离部署，应用程序通过一致性Hash算法选择缓存服务器远程访问缓存数据，缓存服务器之间互不通信，因而集群规模可以轻易地扩容，具有良好的伸缩性。
Memcached由两个核心组件组成：服务端（ms）和客户端（mc），在一个memcached的查询中，mc先通过计算key的hash值来确定kv对所处在的ms位置。当ms确定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以 memcached交互带给网络的影响是最小化的。
（2）异步操作：
①使用消息队列将调用异步化，可改善网站的扩展性，还可改善网站性能；
②消息队列具有削峰的作用->将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务；
PS：任何可以晚点做的事情都应该晚点再做。前提是：这个事儿确实可以晚点再做。
（3）使用集群：
①在高并发场景下，使用负载均衡技术为一个应用构建多台服务器组成的服务器集群；
②可以避免单一服务器因负载压力过大而响应缓慢，使用户请求具有更好的响应延迟特性；
③负载均衡可以采用硬件设备，也可以采用软件负载。商用硬件负载设备（例如出名的F5）成本通常较高（一台几十万上百万很正常），所以在条件允许的情况下我们会采用软负载，软负载解决的两个核心问题是：选谁、转发，其中最著名的是LVS（Linux Virtual Server）。
PS：LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。
LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。有关LVS的详情请参考：http://www.importnew.com/11229.html
（4）代码优化：
①多线程：使用多线程的原因：一是IO阻塞，二是多CPU，都是为了最大限度地利用CPU资源，提高系统吞吐能力，改善系统性能；
②资源复用：目的是减少开销很大的系统资源的创建和销毁，主要采用两种模式实现：单例（Singleton）和对象池（Object Pool）。例如，在.NET开发中，经常使用到的线程池，数据库连接池等，本质上都是对象池。
③数据结构：在不同场合合理使用恰当的数据结构，可以极大优化程序的性能。
④垃圾回收：理解垃圾回收机制有助于程序优化和参数调优，以及编写内存安安全的代码。这里主要针对Java（JVM）和C#（CLR）一类的具有GC（垃圾回收机制）的语言。
四、存储性能优化
（1）机械硬盘 还是 固态硬盘？
①机械硬盘：通过马达驱动磁头臂，带动磁头到指定的磁盘位置访问数据。它能够实现快速顺序读写，慢速随机读写。
②固态硬盘（又称SSD）：无机械装置，数据存储在可持久记忆的硅晶体上，因此可以像内存一样快速随机访问。
在目前的网站应用中，大部分应用访问数据都是随机的，这种情况下SSD具有更好的性能表现，但是性价比有待提升（蛮贵的，么么嗒）。
（2）B+树 vs LSM树
①传统关系型数据库广泛采用B+树，B+树是对数据排好序后再存储，加快数据检索速度。
PS：目前大多数DB多采用两级索引的B+树，树的层次最多三层。因此可能需要5次磁盘访问才能更新一条记录（三次磁盘访问获得数据索引及行ID，一次数据文件读操作，一次数据文件写操作，终于知道数据库操作有多麻烦多耗时了）
②NoSQL（例如：HBase）产品广泛采用LSM树：
具体思想是：将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘。不过读取的时候稍微麻烦，需要合并磁盘中历史数据和内存中最近的修改操作，所以写入性能大大提升，读取时可能需要先看是否命中内存，否则需要访问较多的磁盘文件。
LSM树的原理是：把一棵大树拆分成N棵小树，它首先写入内存中，随着小树越来越大，内存中的小树会被清除并写入到磁盘中，磁盘中的树定期可以做合并操作，合并成一棵大树，以优化读性能。
LSM树的优势在于：在LSM树上进行一次数据更新不需要磁盘访问，在内存即可完成，速度远快于B+树。
参考文献
（1）李智慧，《大型网站技术架构-核心原理与案例分析》，http://item.jd.com/11322972.html
（2）周言之，《Memcached详解》，http://blog.csdn.net/zlb824/article/details/7466943
（3）百度百科，CDN，http://baike.baidu.com/view/8689800.htm
（4）王晨纯，《Web基础架构：负载均衡和LVS》，http://www.importnew.com/11229.html
（5）辉之光，《B树、B-树、B+树》，http://www.cnblogs.com/oldhorse/archive/2009/11/16/1604009.html
（6）yanghuahui''s blog，《LSM树由来、设计思想以及应用到HBase的索引》，http://www.cnblogs.com/yanghuahui/p/3483754.html
关于大型网站技术架构 笔记和大型网站技术架构pdf的介绍现已完结，谢谢您的耐心阅读，如果想了解更多关于<大型网站技术架构：核心原理及案例分析>笔记-->伸缩性架构、BAT架构师分享之：大型网站技术架构、《大型网站技术架构——核心原理与案例分析》第1章：大型网站架构演化、《大型网站技术架构》网站的高性能架构及优化的相关知识，请在本站寻找。
本文标签：
