第一章:大型网站架构演化
一.大型网站软件系统特点:
(1)高并发、大流量
(2)高可用
(3)海量数据
(4)用户分布广泛、网络情况复杂
(5)安全环境恶劣
(6)需求快速变更、发布频繁
(7)渐进式开发
(8)演化发展历程
二.大型网站架构演化原因
在现有架构下,我们来看看数据存储的瓶颈是什么?
(1)数据量的总大小 一个机器放不下;
(2)数据的索引(B+ Tree)一个机器的内存放不下;
(3)访问量(读写混合)一个实例不能承受;
只有当以上3件事情任何一件或多件满足时,我们才需要考虑往下一级演变。
三.大型网站架构演化进程
1. 初始阶段
特点:应用程序、数据库、文件都在一台服务器,如常用的Linux+PHP+Apache+Mysql
2. 应用服务和数据库分离
原因:性能变差、存储空间不足
特点:三台服务器:应用服务器(运算能力:CPU)、文件服务器(更大的存储)和数据库服务器(更大的存储和内存)
3. 使用缓存改善
原因:数据库访问压力太大; 数据访问遵循2-8定律
特点:将访问多的20%的数据放在缓存上,可分为应用服务器端的本地缓存和分布式的远端缓存
4. 应用服务器集群
原因:单一服务器处理的请求链接成为瓶颈
特点:使用应用服务器集群,使用反向代理实现负载均衡、可用性监测、可伸缩的实现
5. 数据库读写分离
原因:使用缓存后,仍有部分读操作和全部写操作要访问数据库,随着规模的增大,这些操作造成数据库瓶颈
特点:数据库进行主从备份和读写分离
6. 使用反向代理和CDN加速网站响应
原因:加速网站访问速度
特点:(1)CDN:部署到客户端最近的网络提供商的机房,用户可从自己最近的网络提供商获取数据,多用于静态内容如CSS、图片等;(2)反向代理:一般代理都是在客户的浏览器端,而此处的代理是在网站端。 用户请求先通过反向代理,反向代理如果缓存有用户需要的资源则立刻返回,否则调用相应服务器
7. 使用分布式文件系统
原因:业务需求继续增大
特点:使用分布式数据库,分库分表
8. 使用NoSQL和搜索引擎
原因:数据存储和检索越来越复杂
特点:NoSQL对可伸缩的分布式特性有很好的支持
9. 业务拆分
特点:将网站拆分成多个应用,每个应用独立维护
10. 分布式服务
特点:将共有业务(用户管理、商品管理等)提取出来独立部署,上层业务复用这些业务完成具体操作
第二章:大型网站架构模式
1. 分层
系统横向维度切分。一般分为应用层(负责具体业务和视图展示,如网站首页和搜索输入和结果展示)、服务层(为应用层提供服务,如用户管理服务、购物车服务等)、数据层(提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等),通过上层对下层的依赖和调用组成完整系统。
2. 分割
系统纵向维护切分,不同的功能和服务分割开,包装成高内聚低耦合的模块单元,然后部署到单独的应用服务器上。
3. 分布式
分层和分割的主要目的就是为了切分后的模块便于分布式部署
常用方案有:
(1)分布式应用与服务:改善性能和复用
(2)分布式静态资源:如JS,CSS独立部署并有独立的域名
(3)分布式数据和存储:对传统数据库使用分布式、采用NoSQL
(4)分布式计算:MapReduce
4. 集群
在多个机器上部署单一模块,提供扩展性、有效性、负载均衡的处理
5. 缓存
条件:某些数据被频繁访问;数据在某个时间段内有效,不会很快过期
有以下方式:
(1)CDN:离用户最近,静态资源
(2)反向代理:网站的前段,静态资源等
(3)本地缓存:应用服务器本机
(4)分布式缓存
6. 异步
使用消息队列实现,单一应用服务器使用多线程之间的消息队列实现异步;分布式环境中使用分布式的消息队列实现异步
好处:降低耦合;加快响应速度;消除并发访问高峰
7. 冗余
实现7*24小时服务,提高可用性
服务器集群实现; 数据库的冷、热备份
8. 自动化
发布过程:自动化代码管理、自动化测试、自动化部署、自动化安全检测
运行过程:自动化监控、自动化报警、自动化失效转移和回复、自动化降级
9. 安全
(1)身份认证: 密码和手机校验码
(2)加密:登录、交易和存储的敏感数据
(3)验证码:机器人程序攻击网站
(4)编码转换:XSS攻击和Sql注入
(5)过滤:垃圾信息和敏感信息
(6)风险控制: 对交易转账等重要操作根据交易模式和交易信息进行
第三章:大型网站核心架构要素
一.性能
1. 定义:用户访问的快慢
2. 评价指标:响应时间,TPS,系统性能计数器
3. 手段:
(1)浏览器方面:浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输、减少HTTP请求
(2)网络方面:使用CDN、反向代理
(3)服务器端:使用本地缓存或分布式缓存、异步模式、集群
(4)代码层次:使用多进程、多线程;优化内存管理
(5)数据库层次:索引、缓存、SQL优化、NoSQL
二.可用性
1. 定义:可以访问的时间
2. 评价指标:几个9,如99.99%
3. 手段:
(1)服务器端:使用冗余、部署多台服务器避免单点;备注:应用服务器无状态,即不保存请求会话信息
(2)数据库进行主从备份
三.伸缩性
1. 定义:通过向集群中加入服务器提高并发访问和数据存储需求
2. 评价指标:是否容易添加新的服务器;新的服务器能否提供无差别服务;服务器数量是否有限制
3. 手段:
(1)应用服务器集群:服务器上不保存数据(无状态)+合适的负载均衡设备
(2)缓存集群:改进缓存路由算法:hash环
(3)数据库集群:路由分区将部署有多个数据库的服务器组成一个集群; NoSQL数据库天生比较好
四.扩展性
1. 定义:快速响应需求变化
2. 评价指标:增加新业务,是否对现有产品透明无影响
3. 手段:
(1)事件驱动架构:利用消息队列,将用户请求和其他业务事件构成消息发布至消息队列,消息的处理者作为消费者从消息队列中获取消息进行处理。
(2)分布式服务:将业务和可复用服务分离开,通过分布式服务框架调用。
五.安全性
1. 定义:现存和潜在攻击手段的应对策略
第四章:瞬时响应:网站的高性能架构
一.网站性能测试
1. 不同视角的网站性能
(1)用户视角
浏览器和服务器通信时间+处理时间+浏览器解析响应数据的时间
2. 开发人员视角
应用程序本身和子系统的性能,有 响应时间、吞吐量、并发处理能力、系统稳定性等指标
3. 运维人员视角
关注基础设施性能和资源利用率,如网络带宽利用率和服务器资源利用率等
手段:建设优化骨干网、定制的服务器、使用虚拟化技术优化资源利用率
二.性能测试指标
1. 响应时间:
执行一个操作需要的时间
测量方法:重复请求,如一个请求重复执行1万次,求得单次平均访问时间
2. 并发数:
同时访问的请求数量
测量方法:模拟并发用户,在两次请求之间加入随机等待时间(思考时间)
3. 吞吐量:
单位时间内处理的请求数量,TPS(每秒事务数)
并发小:吞吐量增加、响应时间小幅上升;并发逐渐增加:吞吐量下降、响应时间快速上升;并发达到崩溃点:吞吐量为0,不响应
4. 性能计数器
描述服务器和操作系统性能的数据指标,如System Load(进程数和CPU数)、内存和CPU使用、对象与线程数
三.性能测试方法
(1)性能测试:以系统规划初期的指标测试
(2)负载测试:增加并发请求,直到多项性能指标达到临界值
(3)压力测试:直到系统崩溃
(4)稳定性测试:特定软硬件条件下,给系统加载一定业务压力,使系统运行一段时间
四.性能优化策略
(1)检查各环节日志
(2)检查监控数据,关注内存、磁盘、网络、CPU
(3)确定是代码问题、架构设计还是系统资源不足
五.Web前段性能优化
1. 浏览器访问优化
(1)减少HTTP请求:通过合并CSS、合并JS、合并图片(如果每张独有不同的超链接,可通过css偏移响应鼠标点击操作,构造不同的URL),减少HTTP请求次数。
(2)使用浏览器缓存:通过设置HTTP头部Cache-Control和Expires属性,来设置浏览器缓存。
(3)启用压缩:对HTML、CSS、JS文件启用GZip压缩, 但会对服务器产生压力。
(4)CSS放在页面最上面、JS放在页面最下面。浏览器会在下载完全部CSS后才进行页面渲染,最好是把CSS放在页面上边;浏览器在加载Js后立刻执行,有可能阻塞整个页面,因此js放在下面,但如果页面解析时就要用到JavaScript的,放在下面就不太合适了
(5)减少Cookie传输。静态资源使用独立域名,避免发送cookie;哪些数据需要写入cookie要慎重考虑
2. CDN加速
CDN本质是一个缓存,部署在网络运营商机房,使得数据缓存在离用户最近的地方,使用户以最快的速度获取数据。
CDN一般缓存静态资源,比如图片、文件、CSS、Script脚本、静态网页等,同时这些文件访问频度很高。
3. 反向代理
传统代理位于浏览器侧,代理浏览器将HTTP请求发送到互联网。反向代理位于网站侧,代理网站Web服务器接收HTTP请求。
反向代理优点:(1)安全;(2)配置缓存可以加速Web请求;(3)负责均衡
六.应用服务器性能优化
1. 分布式缓存
网站优化第一定律:优先考虑缓存优化;缓存实际是内存的hash表;必须合理使用缓存:
(1)频繁修改的数据:读写比在2:1以上
(2)没有热点的访问
(3)数据不一致和脏读:设置失效时间、数据更新时立即更新缓存
(4)缓存可用性
(5)缓存预热:新缓存上没数据
(6)缓存穿透:持续高并发地请求某个不存在的数据,会对数据库造成很大压力
2. 集群
3. 异步
使用消息队列:减少响应延迟、平滑并发访问波动;需要对返回状态做特殊处理,如订单提交(等待消费者处理完后才显示成功)等。
七.代码优化
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
八.存储性能优化
(1)机械硬盘 vs 固态硬盘
(2)B+树 vs LSM树
(3)RAID vs HDFS
第五章:万无一失:网站的高可用性架构
一.可用性的度量和考核
(1)可用性度量: 几个9,如99.99%
(2)可用性考核(对工程师的考核): 故障时间*故障权重
二.高可用的网站架构
企业级采用昂贵的软硬件,如IOE;互联网更多是PC级服务器、开源的数据库和操作系统
主要手段:数据和服务的冗余备份和失效转移。
三.高可用的应用
1. 无状态应用服务器
采用负载均衡软件,一般都提供:心跳检测可用性;失效转移、负载均衡
2. 有状态的应用服务器
(1)session复制:当服务器集群规模下的时候可用。通过开启web容器的session复制功能,让每台服务器上都有用户session信息。 应用在集群规模小的情况下。
(2)session绑定:使用负载均衡软件的源地址hash算法,保证同一IP的处理总在一台服务器上。但使用较少,主要是可用性的问题,如果该机器done了,该用户的session会丢失。
(3)cookie记录session:cookie大小限制;每次都要传输;关闭cookie访问不正常;简单易用;支持应用服务器的线性伸缩。 大部分网站或多或少使用。
(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. 数据采集
(1)用户行为日志收集:服务器端(web服务器)、客户端(javascript)
(2)性能监控
(3)运行数据报告
(4)统计:基于实时计算框架Storm的日志统计和分析工具
2. 监控管理
(1)系统报警
(2)主动失效转移
(3)自动优雅降级
第六章:永无止境:网站的伸缩架构
一.网站架构
1. 根据功能进行物理分离实现伸缩
(1)一台服务器-->数据库分离-->缓存分离-->静态资源从应用服务器分离
(2)纵向分离(按层分割):网络具体产品--可复用业务服务--基础技术服务--数据库
(3)横向分离(业务分割):网站前台--买家前台--卖家后台
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. 负载均衡算法
(1)轮询:请求依次分发
(2)加权轮询:根据服务器的硬件情况加权
(3)随机:好的随机数本身就很均衡,如果硬件配置不同,可使用加权随机
(4)最少链接:记录每个服务器的连接数,新的请求分配到最少的
(5)源地址散列:对IP进行散列,使得该IP的上下文信息存储在这台服务器上,实现会话粘滞
三.分布式缓存
1. 目标:新加入的缓存使得已缓存的数据尽可能能被访问到
2. memchached分布式缓存集群,其中路由算法很重要:
余数hash:缓存数据hashcode/服务器数目。但添加新的缓存服务器就麻烦了,解决方案是使用虚拟节点的一致性hash环
四.数据存储服务器
1. 目标:相对于缓存,对数据的持久性(能存到硬盘)和可用性(能访问到数据)要求更高
2. 关系型数据库
(1)数据库复制:主从读写分离;分库(不同表在不同数据库集群,缺点是不能进行跨库join);分表(产品有Amoeba和Cobar,Cobar可与mysql集群使用)
(2)伸缩的实现:Corba的服务器使用负载均衡;Mysql(Cobar利用Mysql的数据同步功能进行数据迁移)
(3)无法执行跨库Join和事务:避免事务或利用事务补偿机制(分布式事务)代替数据库事务;分解数据访问逻辑避免JOIN操作
(4)支持JOIN的,如GreenPlum,但延迟比较大
3. NoSql数据库
Apache 的HBase,依赖于可分裂的HRegion(数据块)和HDFS(分布式文件系统)。使用者无需处理
第七章:随需应变:网站的可扩展架构
一.构建可扩展的网站架构
软件架构师最大的价值不是掌握多少先进技术,而在于具有将一个大系统切分成N个低耦合的子模块的能力,这些子模块包括横向模块和纵向模块。这种能力是专业的技术和经验,对业务场景的理解,对人性的把握。
1. 核心思想
核心思想是模块化,并在此基础上,降低模块间的耦合性
2. 主要手段
主要手段是分层和分割,模块间通过分布式消息队列和分布式服务聚合
二.利用分布式消息队列降低耦合性
1. 事件驱动架构
借助事件完成模块间合作,常见的是生产者消费者模式,最常用的分布式消息队列
好处:更好的响应延迟;平缓高峰压力;
2. 分布式消息队列
ActiveMQ:除了实现分布式消息队列,在伸缩性(加入队列服务器)和可用性(内存队列满后,写入磁盘)也做了改善。
好处:避免系统当机造成消息丢失,会把发送成功的消息存储在生产者服务器,等消息被消费者处理后才删除消息。
三.分布式服务
纵向拆分:将一个大应用拆分为多个小应用,部署为单独的web系统
横向拆分:将复用业务拆分后部署为分布式服务,新增业务调用这些服务
纵向比较简单,通过梳理业务将较少相关的业务剥离,使其成为独立的web应用。横向不仅要识别可复用的业务,设计服务接口,规范依赖关系,还需要一个完善的分布式服务管理框架。
1. web service与企业级分布式服务
好处:可整合异构系统和构件分布式系统
缺点:臃肿的注册和发现机制;低效的xml序列化;开销相对较高的HTTP远程通信;复杂的部署和维护手段。
2. 大型网站分布式服务的需求与特点
(1)服务注册和发现
(2)服务调用
(3)负载均衡:对热门服务如登录或商品服务,需要部署在集群上
(4)失效转移
(5)高效的远程通信
(6)整合异构系统
(7)对应用最少侵入:尽量使框架和业务独立
(8)版本管理:提供者升级接口发布新版本服务,并同时提供旧版本服务,当请求者调用接口升级后才关闭旧版本服务。
(9)实时监控
3. 分布式服务框架设计
开源的阿里的Dubbo
描述:
(1)消费者通过服务接口调用服务,服务接口通过代理加载服务,代理调用服务框架客户端模块,客户端包括服务提供者列表、负载均衡、失效迁移服务
(2)提供者提供服务管理容器注册服务
(3)支持多种通信协议和序列化协议,使用NIO通信框架,具有较高的网络通信性能
可扩展数据结构
(4)无需修改表字段就可以新增字段,使用NoSql数据库
(5)利用开放平台建立生态圈
(6)提供更多的增值服务,将API开放被第三方开发者使用
第八章:固若金汤:网站的安全架构
一.网站应用攻击和防御
1. XSS攻击
跨站点脚本攻击,有两种:
(1)一种是反射性(在url中 ?<script src... >)
(2)一种是持久型XSS(将恶意脚本的请求保存到数据库中,常用语论坛和博客)
防范手段:
(1)消毒(对提交的文本进行匹配替换,如<img src= 对<进行转义);
(2)HttpOnly(防止xss窃取cookie,即浏览器禁止页面Javascript访问带有HttpOnly的cookie)
2. 注入攻击
需要对数据库有所了解,通过开源(网站使用开源软件搭建);错误回显(从错误信息猜测表结构);盲注(猜测数据库表结构)
防范手段:
(1)消毒(可能注入的sql,如drop table delete from等);
(2)参数绑定(PrepareStatement, ?而不是链接字符串)
3. CSRF攻击
跨站点请求伪造:通过跨站请求,以合法用户身份进行非法操作,关键是识别请求者身份。
防范手段:
(1)表单token、验证码(糟糕的用户体验,只在必要时使用,如支付交易);
(2)Referer check(检查http请求头的referer的请求来源,可用来实现图片防盗链)
4. 其他攻击和漏洞
(1)Error code:获得异常信息,查找系统漏洞; 防范手段:专门的错误页面
(2)html注释: 发布前自动扫描,去除html注释
(3)文件上传:防范手段:设置上传文件白名单,只允许上传可靠的文件类型;修改文件名;使用专门的存储;
(4)路径遍历:在url中使用相对路径;防范手段:动态参数不包括文件路径信息;其他文件不适用静态URL访问
5. web应用防火墙
处理网站攻击的产品,开源的Web应用防火墙:ModSecurity
6. 网站安全漏洞扫描
根据内置规则,构造具有攻击性的URL请求模拟黑客攻击行为
二.信息加密技术和秘钥安全管理
1. 单向散列加密
不能逆转得到明文,字符串微小差别输出差别很大,不同长度输入得到固定长度的输出
常用的有:MD5、 SHA
用于密码加密保存、生成信息摘要
2. 对称加密
算法简单,效率高,系统开销少,适合对大量数据加密;使用同一秘钥,远程通信下如何安全交换秘钥是个难题
常用的有:DES、 RC
用于信息需要安全交换或存储的场合,如Cookie加密、通信加密等
3. 非对称加密
用于信息安全传输、数字签名。
在实际中,常会混合使用对称加密和非对称加密。先使用非对称对秘钥进行安全传输,再使用对称进行信息加密和交换。 有时对一个数据两次使用非对称加密,可同时实现信息安全传输与数字签名的目的。
4. 秘钥安全管理
(1)写到配置文件,线上和线下使用不同的
(2)加密算法放在应用系统中,秘钥放在一个独立的服务器,甚至做成一个专用的硬件设施
(3)秘钥分片后存储在多个服务器
三.信息过滤和反垃圾
1. 文本匹配
敏感词过滤: 正则表达式(敏感词较少、提交的文本长度较短);Trie树(敏感词较多、提交的文本长,如双数组Trie算法);多级Hash表(Trie中相同父节点的字放在Hash表中, 速度较快,浪费部分内存)
2. 分类算法
数据挖掘:分类算法, 贝叶斯算法
3. 黑名单
hash表,布隆过滤器
四.电子商务风险控制
1. 风险
2. 风控
(1)规则引擎: 将业务规则和规则处理分开,业务规则可配置
(2)统计模型:数据挖掘分类算法(当规则增加,出现规则冲突、难以维护时)
第九章:维基百科高性能架构
一.组成部分
(1)GeoDNS:将域名解析到离用户最近的服务器
(2)LVS:Linux的开源负载均衡服务器
(3)Squid:Linux的开源反向代理服务器
(4)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. 允许第一个订单提交
控制进入下单页面入口,只有先提交的少数用户可进入,后边的用户直接进入秒杀结束页面