《大型网站技术架构:核心原理和案例解析》笔记

目录

· 巨型网站软件系统的表征

· 重型网站架构演化发展历程

    · 起来阶段的网站架构

        · 需要/解决问题

        · 架构

    · 应用服务和数据服务分离

        · 要求/解决问题

        · 架构

    · 采用缓存改善网站性能

        · 求/解决问题

        · 架构

    · 运用应用服务器集群改善网站的起处理能力

        · 需要/解决问题

        · 架构

    · 数据库读写分离

        · 需求/解决问题

        · 架构

    · 用反向代理及CDN加速网站应

        · 求/解决问题

        · 架构

    · 使分布式文件系统和分布式数据库系统

        · 急需/解决问题

        · 架构

    · 下NoSQL和查找引擎

        · 需求/解决问题

        · 架构

    · 作业拆分

        · 要求/解决问题

        · 架构

    · 分布式服务

        · 求/解决问题

        · 架构

· 特大型网站架构演化心得

· 大型网站架构模式

    · 综述

    · 分层

        · 概念

        · 目的

        · 举例

    · 分割

        · 概念

        · 目的

        · 举例

    · 分布式

        · 概念

        · 目的

        · 缺点

        · 举例

    · 集群

        · 概念

        · 目的

    · 缓存

        · 概念

        · 目的

        · 举例

    · 异步

        · 概念

        · 目的

    · 冗余

        · 概念

        · 目的

        · 举例

    · 自动化

        · 目的

        · 举例

    · 安全

        · 举例

· 巨型网站为主架构要素

    · 性能

        · 网站性能测试

            · 今非昔比看法下之网站性能

            · 特性测试指标

            · 特性测试方法

            · 属性测试报告

        · Web前端性能优化

            · 浏览器访问优化

            · CDN加速

            · 反向代理

        · 应用服务器性能优化

            · 分布式缓存

            · 异步操作

            · 使集群

            · 代码优化

        · 囤性能优化

    · 可用性

        · 网站可用性的胸襟与考绩

            · 度量

            · 考核

        · 网站架构高可用(总述)

        · 应用层高可用

            · 经过负载均衡进行管状态服务失效转移

            · 应用服务器集群的Session管理

        · 劳务层高可用

        · 数据层高可用

            · CAP原理

            · 数据备份

            · 失效转移

        · 赛可用网站软件质量担保

            · 网站发布

            · 自动化测试

            · 预发布验证

            · 代码控制

            · 自动化发布

            · 灰度发布

        · 网站运行监控

            · 监察数据搜集

            · 督查管理

    · 伸缩性

        · 网站架构的伸缩性设计

            · 今非昔比功能进行物理分离实现伸缩

            · 纯功能通过集群规模落实伸缩

        · 应用服务器集群的紧缩性设计

            · HTTP重定向负载均衡

            · DNS域名解析负载均衡

            · 反向代理负载均衡

            · IP负载均衡

            · 多少链路层负载均衡

            · 负载均衡算法

        · 分布式缓存集群的紧缩性设计

        · 数量存储服务集群的伸缩性设计

            · 关系数据库集群的紧缩性设计

            · NoSQL数据库集群的伸缩性设计

    · 扩展性

        · 扩展性与伸缩性

        · 构建而扩大的网站架构

        · 动分布式消息队列降低系统耦合性

        · 下分布式服务打造而复用的政工平台

    · 安全性

        · 网站采取攻击和防御

            · XSS攻击

            · 流入攻击

            · CSRF攻击

        · Web应用防火墙

        · 网站安全漏洞扫描

        · 信息加密技术及密钥安全治本

            · 惟有为散列加密

            · 针对如加密

            · 未对如加密

        · 密钥安全治本

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

    · 秒杀活动的技能挑战

    · 秒杀系统架构设计


 

巨型网站软件系统的特色

暨传统企业应用相比,大型互联网采用系统发出以下特征:

  1. 高并发,大流量;

  2. 强可用:系统7×24钟头免间歇服务;

  3. 海量数据:需要仓储、管理海量数据,需要动用大量服务器;

4.
用户分布广泛,网络状态复杂:许多大型互联网都是为海内外用户提供劳务之,用户分布范围广泛,各地网络状态差别;

5.
安康环境恶劣:由于互联网的开放性,使得互联网更易受攻击,大型网站几乎每天还见面受黑客攻击;

6.
需要迅速转移,发布频繁:和习俗软件的本发布频率不同,互联网产品也高效适应市场,满足用户需求,其出品发布频率是最好高之;

7.
渐进式发展:与俗软件出品或者企业应用系统一样开始即计划好合的意义与非功能需求不同,几乎拥有的特大型互联网网站都是于一个小网站开始,渐进地开拓进取起来的。

重型网站架构演化发展历程

千帆竞发阶段的网站架构

需/解决问题

稍许网站极度初步并未太多人口走访。

架构

应用程序、数据库、文件等具有的资源且在同等光服务器上。

图片 1

应用服务和数据服务分离

需/解决问题

趁网站工作的升华,越来越多之用户访问导致性更差,越来越多的数码造成存储空间欠缺。

架构

应用与数量分离后一切网站使用三宝服务器,其针对性硬件资源的渴求各不相同:应用服务器处理大量业务逻辑,需要重新快又有力的CPU;数据库服务器快速磁盘检索和数量

缓存,需要重快的磁盘和重新甚之内存;文件服务器存储大量用户上传的文本,需要再次怪之磁盘。

图片 2

动缓存改善网站性能

需/解决问题

用户逐渐增多,数据库压力最要命招访问延迟。

架构

基于二八定律:80%的事务访问集中在20%之多寡上,把粗片段数据缓存在内存中,可减少数据库访问压力。

类型

原理

优点

缺点

本地缓存

缓存在应用服务器

访问速度更快

受应用服务器内存限制

分布式缓存

部署大内存缓存服务器集群

理论上不受内存容量限制

 图片 3

运应用服务器集群改善网站的起处理能力

要求/解决问题

纯净应用服务器能够处理的伸手连接有限。

架构

Scale up有限,Scale out无限,所以应用服务器要Scale out。

 图片 4

数据库读写分离

需求/解决问题

有的诵读操作(缓存访问不命中、缓存过期)和周之状操作需要看数据库。

架构

应用服务器写多少常常,访问主数据库,主数据库通过主从复制机制以数据更新同步到打数据库;当应用服务器读数据常常,可通过自数据库获得数据。通常以应用服务器端应用特别的数目访问模块,使数据库读写分离对采用透明。

图片 5

下反向代理及CDN加速网站应

求/解决问题

中国罗网环境复杂,不同地方的用户访问网站时,速度差别大,网站访问推迟导致用户流失率提高。

架构

CDN和倒往代理目的都是快返回数据、加快访问速度、减轻后端服务器负荷压力。

1.
CDN:部署在网提供商机房。用户要网站服务时,可起离开自己近年来之纱提供商机房获取数据。

2.
相反往代理:部署于网站基本机房。用户请求到达为主机房后,首先访问反向代理服务器,如果反往代理服务器缓存着用户请求的资源,就用那一直回给用户。

图片 6

动用分布式文件系统和分布式数据库系统

需求/解决问题

念写分离伸缩性有限。

架构

只有以单表数据规模大庞大之时刻(不至万无奈)才数据库拆分,按工作分库,不同之工作数据部署在不同的情理服务器上。

图片 7

应用NoSQL和摸索引擎

需/解决问题

乘势网站工作尤其复杂,对数据存储和查找的要求吗进一步复杂。

架构

  1. NoSQL和摸索引擎都是根互联网的技术手段,可伸缩的分布式特性还好;

  2. 应用服务器通过一个联结数看模块访问各种数据。

图片 8

业务拆分

要求/解决问题

事务场景日益复杂。

架构

1.
用全方位网站工作分成不同产品线(如大型购物交易网站拆分为首页、商铺、订单、买家、卖家),分归不同工作集团负责。

2.
因产品线分割,将网站拆分成不同应用,每个应用独立布置维护。应用中关系方式:

    a) 超链接(首页上导航链接每个应用地址);

    b) 通过信息队列进行数据分发;

    c) 通过平等数据存储系统做一个关联的完好系统(最多)。

图片 9

分布式服务

求/解决问题

怀有以要跟兼具数据库系统链接,在数万贵服务器规模之网站遭遇,连接数目时服务器规模的平方,导致数据库连接资源贫乏,拒绝服务。

架构

以同用之事务提取出服务,独立布置。

图片 10

巨型网站架构演化心得

1.
大型网站架构技术的基本价值不是自管至起多建筑一个重型网站,而是会伴随小型网站业务的逐渐提高,慢慢地演变成一个巨型网站。

  1. 俾大型网站技术进步之基本点力量时网站的作业发展。

  2. 技术是故来解决工作问题的,而工作问题,也得以经作业手段去解决。

    a)
12306之题目无在于技术架构,而介于业务架构:几亿华相同批难求的事态下,零点起发售多少天后的车票;

    b) 解决:售票方法达成引入排队机制、整点售票调整为分时段售票。

巨型网站架构模式

综述

1.
模式:每一个模式描述了一个在咱们周围不断重复发生的题目及该问题迎刃而解方案的骨干。这样,你虽可知同差而同样差地使该方案一经毋庸做还工作。

2.
网站架构模式:大型互联网企业在实践中提出了众解决方案,以落实网站大性能、高可用、易伸缩、可扩大、安全等各种技术框架目标。这些解决方案以为再次多网站重复使用,从而逐步形成大型网站架构模式。

分层

概念

1.
用系统于横向维度上切分成几独片,每个片承担一部分相对比单一的天职,然后经过上层对下层之因以及调用组成一个完全的体系。

  1. 执行备受,大之分支结构里还可持续分层。

目的

  1. 造福分工合作开发暨保安;

2.
各级层独立,只要保持调用接口不更换,各层可依据现实问题独立演化发展使不论是需任何层必须相应调整;

3.
大体部署达成,三交汇结构可配备于一如既往物理机械及,随着网站工作发展,必然要分别部署,其三层结构分别配备在不同服务器,使网站有着双重多算资源报重多用户访问

问。

举例

应用层

负责具体业务和视图展示,如网站首页及搜索输入和结果展示

服务层

为应用层提供服务支持,如用户管理服务,购物车服务等

数据层

提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等

分割

概念

1.
自纵向方面针对软件进行切分,将不同作用及劳动分割开来,包装成高内集聚低耦合的模块单元。

  1. 重型网站分割粒度可能会见生有些。

目的

  1. 促进软件开发和护卫;

  2. 便利不同模块的分布式部署,提供网站的产出处理能力与机能扩展能力。

举例

1.
以应用层,按工作分割为购物、论坛、搜索、广告不同的以,独立团队负责,部署于不同服务器;

2.
同一应用内,如果局面庞大业务复杂,会持续分割,比如购物业务分割为机票酒店工作、3C业务、小商品业务等又细致小的粒度。

分布式

概念

分和撤并的一个最主要目的是为切分后的模块便于分布式部署,即不同模块部署于不同服务器上,通过远程调用协同工作。

目的

不过利用更多的电脑完成同样的功用,计算机尤其多,CPU、内存、存储资源也尤为多,处理并发访问和多少两便越发老。

缺点

  1. 分布式服务调用必须透过网络,可能会见影响属性;

  2. 服务器越多,服务器宕机概率就进一步怪;

  3. 分布式环境数据一致性非常拮据,分布式事务也不便管教;

  4. 分布式导致网站因错综复杂,开发管理保护困难。

举例

  1. 分布式应用和服务:将分和撤并后的动与劳动模块分布式部署。

2.
分布式静态资源:网站的静态资源如JS、CSS、Logo图片等资源独立分布式部署,并使用独立域名,即动静分离。

3.
分布式数据和储存:大型网站要处理为P为单位之雅量数据,单台计算机无法提供这样好的囤空间,此时待分布式存储。

4.
分布式计算:严格来说,应用、服务、实时数据处理还是测算,网站除了使处理这些在线工作,还有非常非常片段后台业务,包括搜索引擎的目录构建、数据仓库的数目解析统计等。

集群

概念

由此负载均衡技术也一个运用构建一个几近华服务器组成的集群,共同对外提供劳动。

目的

提高系统可用性。

缓存

概念

以数据存放于离开计算最近的职务。

目的

加紧处理速度。

举例

  1. CDN。

  2. 反向代理。

  3. 本地缓存。

  4. 分布式缓存。

  5. 以上4单还在头里章节已证实,不再赘述。

异步

概念

1.
纯净服务器间可经过多线程共享内部队列方式贯彻异步,业务操作前的线程将出口写副行,后面的线程从队列读取数据处理。

  1. 分布式系统中,多单服务器集群通过分布式消息队列实现异步。

目的

1.
增高系统可用性:消费者服务器出故障,数据会在信息队列服务器存储堆积,生产服务器可以连续处理事务要,系统整体呈现无故障。消费者服务器恢复正常后,继续处理消息队列中之多少。

2.
加快网站响应速度:业务处理前端的生在服务器将数据形容副消息队列,无需等待买主服务器处理就可回到,响应延迟减少。

3.
败并发访问高峰:用户访问网站是不管三七二十一的,虽然存在山上与低谷,但突发事件(促销活动、微博热事件)会招致网站出现访问突然增大。使用信息队列将出人意料多的走访请求数据放入消息队列,等待买主服务器依次拍卖,减多少网站负载压力。

  1. 解耦,提升扩展性。

图片 11

5.
通病:消费者服务器处理(如工作校验、写数据库)失败,以订单提交也例,可每当中标交付后Email或短信通知用户订单成功,避免贸易纠纷。

冗余

概念

别劳动还必须配备至少少贵服务器构成的一个集群。

目的

兑现服务大可用。

举例

  1. 冷备客:定期备份,存档保存。

  2. 热备份:主从分离,实时同步。

自动化

目的

减少人数吧干预,减少故障。

举例

  1. 自动化发布。

    a)
自动化代码管理:代码版本控制、代码分支创建合并等经过自动化,开发工程师只要交自己参与开发的成品代号,系统活动为其创立开发分支,后期自动合并代码。

    b)
自动化测试:代码开发成功,提交测试后,系统自动将代码部署至测试环境,启动自动化测试用例测试,向相关人员发送测试报告,向网反映测试结果。

    c)
自动化安全检测:安全检测工具对代码静态安全扫描和配置到平安测试环境进行安全攻击测试,评估安全性。

    d) 自动化部署:将工程代码自动部署至线上生条件。

  1. 自动化监控。

    a)
自动化报警:对线上产环境自动化监控,对劳动器心跳检测,及各类性能指标和应用程序的重要性数据指标。如果发现异常、超出预设阀值,自动化向相关人员发送报警,警告故障或产生。

    b)
自动化失效转移:检测及故障发生后,系统自动化将失效服务器从集群隔离,不再处理要。

    c)
自动化失效恢复:待故障排除后,系统自动化重新启航服务,同步数据保证数据一致性。

    d)
自动化降级:网站逢访问高峰,超出网站极度可怜拍卖能力时,为力保所有网站安全可用,会自动化拒绝部分呼吁与倒闭部分无重大服务用系统负荷降到安康程度。

    e) 自动化分配资源:将空闲资源分配给关键服务,扩大部署规模。

安全

举例

  1. 经过密码以及手机验证码身份验证。

2.
报到、交易等操作需网络通信加密,网站服务器上囤积的精灵数据为加密处理。

  1. 利用验证码辨识,防止机器人程序滥用网络资源攻击网站。

  2. 本着科普的用来攻击网站的XSS攻击、SQL注入进行编码转换等处理。

  3. 本着污染源信息、敏感信息过滤。

  4. 对交易转账等主要操作根据市模式与市信息进行风险控制。

特大型网站为主架构要素

性能

网站性能测试

不等视角下之网站性能

1.
用户意见:用户在浏览器上直观感受及之网站相应速度,包括用户电脑及网站服务器通信的速度、网站服务器处理的速、用户电脑浏览器构造请求解析响应数据的快。

2.
开发人员视角:应用程序本身及其相关子系统的特性,包括应延迟、系统吞吐量、并作处理能力、系统稳定等技术指标。

3.
运维人员意见:基础设备性能与资源利用率,如网运营商的牵动富、服务器硬件的布、数据主导网架构、服务器和网带宽的资源利用率等。

属性测试指标
  1. 响应时间

    a) 解释:从发出请求开始交接收最后应数据所用之工夫。

    b) 意义:系统最要之性能指标。

    c)
测试方法:测试程序通过模拟应用程序,记录收到响应和生呼吁中的年月不同;通常还请求,取平均值。

    d) 常用系统操作响应时间表。

操作

响应时间

打开一个网站

几秒

在数据库中查询一条记录(有索引)

十几毫秒

机械磁盘一次寻址定位

4毫秒

从机械磁盘顺序读取1MB数据

2毫秒

从SSD磁盘顺序读取1MB数据

0.3毫秒

从远程分布式缓存Redis读取一个数据

0.5毫秒

从内存中读取1MB数据

十几微妙

Java程序本地方法调用

几微妙

网络传输2KB数据

1微妙

  1. 并发数

    a)
解释:同时处理要的数额,反映了系统的负载特性。网站并发数指“并发用户数”。

    b) 并发用户数:同时提交请求的用户数据。

    c) 在线用户数:当前报到网站的用户数据。

    d)
系统用户数:可能拜会系统的总用户数,对大部分网站而言就是是报用户数。

    e)
三者数量较关系:系统用户数>>在线用户数>>并发用户数。

    f)
意义:网站产品设计初期,产品经营和运营人员如统筹不同发展等网站系统用户数,以之吧底蕴,推算在线用户数及产出用户数,这些指标是非功能设计的重要依据。

    g)
测试方法:测试程序多线程模拟并发用户测试并发处理能力;测试程序并无多线程不停歇发送请求,而是片次呼吁中加随机等待时,模拟用户考虑时。

  1. 吞吐量

    a) 解释:单位时外网处理的恳求数量。

    b)
常用量化指标:“请求数/秒”或“页面数/秒”、“访问人数/天”或“处理的作业数/小时”、TPS(每秒事务数)、HPS(每秒HTTP请求数)、QPS(每秒查询数)。

    c)
三者关系:并发数由小逐增过程中,服务器资源消耗逐增,吞吐量逐增,响应时间增长率上升;达到吞吐量极限后,并发数增加反降低,响应时间快速上升;达到系统崩溃点后,系统资源耗尽,吞吐量也零星,失去响应。

图片 12

  1. 性能计数器

    a) 解释:描述服务器或操作系统性能有数指标,包括System
Load、对象以及线程数、内存以、CPU以、磁盘与网络IO等。

    b)
意义:系统监控的要参数,监控网发现性能计数器超过阀值时,向运维人员报警,及时发现处理非常。

    c) System
Load(系统负荷):当前着让CPU执行与等给CPU执行之经过数目总和,反映系闲忙程度的主要指标。多核CPU情况下,Load值等于CPU数目时,说明所有CPU都当动,没有CPU不足以及空;Load值大于CPU数目时,说明经过排队等候CPU调度,资源贫乏;Load值小于CPU数目时,说明CPU空闲。Linux的“top”命令可查询最近1分钟、10分钟、15分钟的运转班平均进程数。

图片 13

属性测试方法
  1. 性能测试是总称,细分为:

    a)
性能测试:以网规划初期规划的性能指标为预期目标,不断施加压力(增加并发请求),验证系统于资源而承受范围,可否达到预期。

    b)
负载测试:不断施加压力(增加并发请求),直到某项或多项性能指标达到安全到界值(比如资源已经饱和)。此时延续加压,系统处理能力会骤降。

    c)
压力测试:超过安全负载情况下,不断施加压力(增加并发请求),直到系统崩溃或无法处理外要,依此获得系统最可怜压力承受能力。

    d)
稳定性测试:被测试网在一定硬件、软件、网络环境下,加载一定工作压力(模拟生产条件差时间点、不都匀请求,呈波浪特性)运行一段较长时间,以此检测体系是否平安。

2.
属性测试曲线:横坐标为吃的系统资源,纵坐标为吞吐量。a~b为网站一般运转间隔,c为系统最可怜负载点,d为系统崩溃点。

图片 14

特性测试报告

并发数

响应时间(ms)

TPS

错误率(%)

Load

内存(GB)

备注

10

500

20

0

5

8

性能测试

20

800

30

0

10

10

性能测试

30

1000

40

2

15

14

性能测试

40

1200

45

20

30

16

负载测试

60

2000

30

40

50

16

压力测试

80

超市

0

100

不详

不详

压力测试

Web前端性能优化

浏览器访问优化
  1. 调减HTTP请求:合并CSS、合并JavaScript、合并图片。

2.
使浏览器缓存:CSS、JavaScript、Logo、图标等静态资源文件更新频率比较逊色,通过HTTP头Cache-Control和Expires设置缓存数龙,甚至几单月。更新此类文件时,不创新内容,而是修改文件称,生成新文件并更新HTML引用。当有雷同批此类文件要更新时,不宜同破全翻新,而是逐个更新,并产生时间距离,以免浏览器大量缓存失效,集中更新缓存,服务器负荷剧增。

3.
启用压缩:文本文件(如HTML、CSS、JavaScript)GZip压缩率可达成80%之上,有效削减通信传输数据量。但服务器、浏览器压力升高,所以要权衡。

4.
CSS放在页面最上面,JavaScript放在页面最下:浏览器下载全部CSS后才渲染页面,而当加载JavaScript后这实施,可能会见卡住页面,渲染缓慢。

5.
减Cookie传输:每次要和响应都见面含有Cookie,影响多少传;静态资源访问(如CSS、JavaScript)发送Cookie无意义。可静态资源以独立域名,避免请求静态资源时发送Cookie。

CDN加速

前面章节已说明,不再赘言。

图片 15

反向代理

眼前章节已证实,不再赘言。

图片 16

应用服务器性能优化

分布式缓存
  1. 网站性能优化第一定律:优先考虑采取缓存优化性能。

2.
缓存有点:缓存访问速度快,减少数额看时间;如果缓存的数量是经过计算得到的,则此类数据无需重新计算而一直采用。

3.
缓存本质:以相同对准Key、Value形式存储于内存的Hash表,读写时间复杂度O(1)。

图片 17

  1. 采用缓存注意事项。

    a)
频繁修改的数:如果缓存频繁修改的数目,会招致写副缓存后来不及读取已失效。一般数量读写于应在2:1以上,甚至更胜。

    b)
没有看好的访问:缓存使用内存,资源宝贵,应按二八定律,即缓存20%热数据。

    c)
数据未同等和脏读:一般安装缓存失效时,失效后打数据库加载,因此若忍一定时间的数量不相同。也只是数量更新时即时更新缓存,但会带重新多系统开发和业务一致性问题。

    d)
缓存可用性:为免缓存雪崩(缓存不可用造成数据库无法接受压力要宕机),可拿缓存数据分布至集群多贵服务器,宕机时就出一些缓存数据丢失。

    e) 缓存预热(warn
up):热点数据是经过LRU(最近最为久远不就此算法)淘汰生成的,需较长时间。

    f)
缓存穿透:缓存不存在的数(其值为null),避免不得体业务还是恶意攻击高并发请求某个不存数量,造成数据库压力而夭折。

异步操作

前章节已说明,不再赘言。

使用集群

前方章节已证实,不再赘言。

图片 18

代码优化
  1. 多线程

    a)
目的:利用多线程IO阻塞和实施交替进行,最深限度利用CPU资源;多线程最酷限度利用基本上核CPU。

    b)
Web容器线程数设置:如果都是CPU计算型任务,则线程数最多未越CPU内核数(更多线程CPU来不及调度);如果还是伺机磁盘IO、网络IO的天职,则多启动线程有助于增强任务并发度,提高吞吐力。

  1. 资源复用:单例(Singleton)、对象池(Object Pool)。

  2. 数据结构。

  3. 污染源回收:即优化JVM。

存储性能优化

或许临时未重大,以后得常当羁押开。

可用性

网站可用性的心气与考核

度量
  1. 业界一般用略带个9来衡量网站可用性。

  2. 网站未可用也如网站故障。

  3. 网站不可用时公式:

    网站不可用时(故障时)= 故障修复时点-故障发现(报告)时间接触

  4. 网站年度可用性指标公式:

    网站年度可用性指标 =(1-网站不可用时/年度总时)×100%

  5. 普遍可用性:

可用性(9)

可用性(百分比)

网站不可用时间

说明

2个9

99%

小于88小时

 

3个9

99.9%

小于9小时

 

4个9

99.99%

小于53分钟

具有自动恢复能力

5个9

99.999%

小于5分钟

可用性极高

考核
  1. 故障分:对网站故障进行归类加权测算故障责任的艺术。

  2. 网站故障分类权重表(示例)

分类

描述

权重

事故级故障

严重故障,网站整体不可用

100

A类故障

网站访问不顺畅或核心功能不可用

20

B类故障

非核心功能不可用,或核心功能少数用户不可用

5

C类故障

以上故障以外的其他故障

1

  1. 故障分公式:

    故障分=故障时(分钟)×故障权重

4.
考核过程:年初要考核季度开经常,根据网站产品可用性指标计算总的故障分,然后因集团和民用职责角色分摊故障分,这个可用性指标及故障分是治本预期;故障发生后,根据故障分类及权责划分给故障发生的故障分分配给责任者承担;年末还是考核季度末时,个人与集体实际负担的故障分要跨越年度分摊的故障分,绩效考核受到震慑。

网站架构高可用(总述)

  1. 因百度为例。

    a) 应用层:文库、贴吧、百科等属于不同产品,各自独立布置集群。

    b) 服务层:应用层产品靠共同之复用业务,这些业务服务各自安排集群。

    c) 数据层:各自安排集群。

图片 19

  1. 实现高可用架构主要招数:数据以及劳务之冗余备份及失效转移。

3.
应用层高可用:通过负载均衡设备将平组服务器组成一个集群对外处理高并发请求,负载均衡设备经过心跳检测等招数监督到应用服务器不可用时,将该于集群列表剔除,请求分发及集群其他可用服务器上。

4.
劳动层高可用:也是通过集群实现高可用。服务层被应用层通过分布式服务调用框架看,分布式服务调用框架在动用层客户端中贯彻负载均衡,服务登记中心获得服务层服务器心跳检测,发现未可用服务器,立即通知客户端修改服务层访问列表,剔除不可用服务器(说的就是是Dubbo)。

5.
数据层高可用:比较奇特,数据服务器存储了数据。数据写入时协同复制数据及大半令服务器上,实现数据冗余备份;数据服务器宕机时,数据访问切换至备份数据服务器上。

  1. 网站升级发布或者引起故障。

应用层高可用

经负载均衡进行无状态服务失效转移

不论是状态下:应用服务器不保留业务的上下文信息,而只冲每次要提交的数码处理工作逻辑,多令服务器中全对顶,请求提交到任意服务器结果一致。是应用层高可用之基础。

图片 20

应用服务器集群的Session管理

实在业务总是发生状态的(Session),负载均衡集群环境下,负载均衡服务器可能会见用请求分发到集群任何依他应用服务器上,所以每次要获取科学的Session要于单机复杂。几种植手段:

1.
Session复制:集群各台服务器间同步Session对象,每令服务器都保存有用户的Session信息。服务器内存无法保存大量Session,不适合大型网站。

图片 21

2.
Session绑定:利用负载均衡的源地址Hash算法,负载均衡服务器总是用来自同一IP的恳求分发至平服务器。服务器宕机Session丢失,无法高可用,不符合大型网站。

图片 22

3.
用到Cookie记录Session:Cookie大小限制;每次要响应都传Cookie,影响属性;用户关闭Cookie将非正规。Cookie简单易用,可用性高,支持应用服务器线性伸缩,许多网站还是多要有失都以Cookie记录Session。

图片 23

4.
Session服务器:利用分布式缓存、数据库等存取Session,实现应用服务器的状态分离。可用性高、伸缩性好、性能是,适合大型网站。

图片 24

劳层高可用

  1. 分级管理。

    a) 核心应用以及劳动先行使用还好的硬件与再次快之运维响应速度。

    b)
部署隔离,避免故障有关反应:低优先级服务启动不同线程或配备于不同虚拟机上割裂;高优先级劳动配置在不同物理机上;核心服务和数目竟然部署在不同地方的多少核心。

2.
超时设置:在应用程序设置服务调用超时时间,超时后通信框架抛来异常,避免为服务器宕机、线程死锁导致应用程序对服务端调用失去响应,进而用户要长日子得不交应,同时占用应用程序资源。

  1. 异步调用:前面章节已证实,不再赘述。

  2. 劳务降级:有少种植手段。

    a)
拒绝服务:拒绝低优先级应用之调用,减少并发数,确保基本应用正常调用;随机拒绝部分要调用,让另外一样片要成功,避免大家并非常的餐具。

    b)
关闭服务:关闭部分非紧要服务还是服务中关门部分无重大意义,节约开支。

5.
幂等性设计:应用层只要不接调用成功的响应,都看调用服务失败,并重试服务调用,因此服务层必须确保服务又调用和调用一涂鸦的结果同样,即服务有幂等性。

数据层高可用

CAP原理
  1. 数码高可用含义。

    a) 数据持久性:在各种场面下还无见面面世数丢失问题。

    b)
数据可访问性:多数据副本分别存放于不同存储设备情况下,失效转移会挺快就(终端用户几乎从未感知)。

    c) 数据一致性:多多少副本情况下,各副本中数据一致。

2.
CAP规律:一个提供数据服务之贮存系统无法同时满足数量一致性(Consistency)、数据可用性(Availability)、分区耐受性(Partition
Tolerance)这三单原则。

图片 25

3.
大型网站实行:通常选择强化分布式存储系统的可用性(A)和伸缩性(P),而当某种程度上放弃一致性(C)。一般数量不等同出现在网高并发写操作还是集群状态不安静(故障恢复、集群扩容等)时,应用体系如指向分布式数据处理体系的数量不一致性有打探并进行某种意义上之续与纠错,以保险最终一致性。

4.
比喻:2012年淘宝“双十一”,活动始于率先分钟即涌入1000万独门用户访问,极端的高并发对数码处理体系造成巨大压力,存储系统较弱的数量一致性导致部分商品超卖。

数据备份
  1. 冷备。

    a) 优点:简单、廉价,成本以及技术难度都于逊色。

    b) 缺点:无法保证数据一致性(备份设备中的多寡较系统中之数据陈旧)。

    c) 现状:作为传统的数据保护手段仍以运维中运用。

  1. 热备。

    a)
异步热备:多客数据副本的写入操作异步完成,即应用程序收到数据服务系统的刻画操作成响应时,只写成功了相同客,存储系统将异步地形容其他副本(该过程可能破产)。

图片 26

    b)
同步热备:多卖数据副本的写入操作并完成,即应用程序收到数据服务系统的写成功响应时,多卖数据还早已写操作成。

图片 27

3.
一同热备优化:应用程序客户端并作于多只存储服务器又写副数据,所有写操作成响应后,再通报应用程序成功。优点:存储服务器无主从之分,完全对顶,便于管理维护;并发写操作表示多份数据的总写操作延时凡应最缓慢的那么尊存储服务响应。

4.
实际:通常用读写分离,写操作才看Master数据库,读操作就看Slave数据库。

失效转移

1.
失效确认:有私心跳检测与应用程序访问失败报告两种手段。对于后者,控制中心还要还同破发送心跳检测确认,以免错误判断服务器宕机。

图片 28

  1. 访问转移:将数据读写访问重新路由于至外服务器上。

3.
数据恢复:数据副本数目已经缩减,必须以副本数目恢复至网设定的价,否则再发宕机可能无法访问转移(所有副本服务器宕机)。

赛可用网站软件质量担保

网站发布
  1. 网站公布是一模一样不成提前预知的服务器宕机,过程得重复平和,对用户影响更小。

  2. 便使用发布脚论就披露。

图片 29

自动化测试
  1. 目的:回归测试,以保证没有引入无料的Bug;测试浏览器兼容性。

2.
实在:大部分网站使用Web自动化测试,使用自动化测试工具或脚本完成测试。如Selenium。

预发布验证

1.
原因:测试环境和线上环境不同,特别是用靠之劳动(如数据库、缓存、功用业务服务、电信短信网关、银行网银接口等)。

2.
办法:先发布到预发布上,工程师在预发布服务器上证实(如实行典型工作流程)后,确认无误才正式宣告。预发布服务器和丝及标准服务器唯一的区分是从未有过安排于负载均衡服务器上,外部用户无法访问。

图片 30

代码控制

1.
着力开发、分支发布:在主导上修修改改代码,发布时,从主干拉一个岔发布;如果发现Bug,继续于拖欠分上改发布,并将改合并回主干。

    a)
优点:主干代码反映总体应用之状态,一目了然,便于管理,也有利于持续集成。

    b) 缺点:A功能发布的时节,B功能时半成品,导致A无法发布。

2.
子发布、主干发布:不得以中心上一直改动,开发新力量要修复Bug时,从主干拉一个支行出,完成都测试通过后,合并回主干,然后起基本发布,主干上代码永远是时髦发布的本。

    a) 优点:各支行独立,互不干扰,使不同发布周期的开销以平应用进行。

    b) 网站开发主要采取该方法。

自动化发布

1.
定位发布日期:很多网站选择周四作发布日,这样同样圆前来三天时间准备发布,后面还有一样上时间得扭转错误。如果选周五宣布,发现题目不怕得要周末加班加点了。

2.
列车发布模型:每个应用发布过程作为一不好列车旅行,火车一定运行,期间发生几站点,每一样立都例行检查,不经之路下车,剩下的下项目后续以火车旅行,直到火车顶到顶点(发布成功)。有或持有类型都下车,那么空车前进是从来不意义的,火车要回到起点,等待问题化解再又来。还有可能车上有重点项目,他起了错,大家还与着重来。

图片 31

  1. 列车发布模型基于规则驱动流程,所以可以自动化。
灰度发布
  1. 目的:大型网站集群规模颇巨大,故障发生后回滚需要非常丰富日子完成。

2.
艺术:将集群服务器分为多有,每天只宣布其中部分,观察稳定无故障后,持续几龙才拿任何集群全部揭晓了,期间发现问题,只要回滚已披露的一致部分服务器。

图片 32

网站运行监控

监督数据收集

广义上网站监控涵盖所有不直接工作行为之多少收集和管制,包括数据解析师和产品设计师的网站用户作为日志、业务运行数据,运维工程师和支出工程师使用的系性能数据等。

1.
用户作为日志收集:用户以浏览器上的富有操作及其操作环境,包括操作系统、浏览器版本、IP地址、页面访问路径、网页停留时间等,对统计网站PV/UV、分析用户作为、优化网站设计、个性营销与引进生关键。

    a)
服务器端日志收集:优点是简简单单,Web服务器都支持;缺点是失真(如代理服务器IP非真实IP),无法甄别访问路径。

    b)
浏览器日志收集:优点是精准;缺点是较费心,在页面嵌入JavaScript收集。

    c)
日志处理:数据量惊人,存储和计量压力好,许多网站因实时计算框架Storm日志统计和分析。

2.
服务器性能监控:收集服务器性能指标,如系Load、内存占用、磁盘IO、网络IO等。

    a)
目的:尽早故障预警,防患于未然;合理安排集群规模、改善性和调动伸缩性的根据。

    b) 工具:Zabbix、Ganglia、Nagios。

督查管理

1.
系统预警:超过预设阀值意味着可能出现故障,此时透过邮件、短信等艺术报警。

2.
失效转移:除应用程序访问时失效转移,监控体系于意识故障时积极通报下失效转移。

  1. 机关优雅降级:前面章节已证实,不再赘言。

伸缩性

网站架构的伸缩性设计

差作用进行物理分离实现伸缩
  1. 计:不同服务器部署不同服务,提供不同作用。

2.
纵向分离(分层后分手):将事情处理流程达到的例外部分分离部署,实现伸缩性。

图片 33

  1. 横向分离(业务分割后分手):将不同之事务模块分离部署,实现伸缩性。

图片 34

纯净功能通过集群规模落实伸缩

道:集群内之多台服务器部署相同服务,提供相同功能。

应用服务器集群的伸缩性设计

  1. 负载均衡器:HTTP请求分发装置。

  2. 负载均衡:同时实现伸缩性和可用性,可谓网站的绝技。

HTTP重定向负载均衡

1.
规律:HTTP重定向服务器根据用户的HTTP请求计算同一令真正Web服务器地址,将欠地点写副HTTP重定向响应(状态码302)返回用户浏览器。

图片 35

  1. 优点:简单。

3.
通病:浏览器两次于呼吁服务器才能够不辱使命同样坏拜访;302态码重定向可能只要搜索引擎判断为SEO作弊,降低搜索排行。

  1. 实际:不多见。
DNS域名解析负载均衡
  1. 规律:DNS服务器遭受布局多单A记录(如www.mysite.com IN A
    114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A
    114.100.80.3),每次域名解析呼吁都见面因负荷均衡算法计算一个IP地址返回。

图片 36

2.
独到之处:负载均衡交给DNS,省去维护负载均衡服务器的劳动;DNS支持因地理位置的辨析,即解析距离用户最近底服务器地址。

3.
弱点:服务器下线时,更新DNS解析生效时间较丰富;DNS负载均衡控制权在域名服务商,无法对该再多改善及治本。

4.
实际:大型网站以DNS解析作为第一层负载均衡,即解析得到的如出一辙组服务器是内负载均衡服务器,再由中间负载均衡服务器分发及真是Web服务器。

反向代理负载均衡

1.
原理:反向代理同时落实了缓存和负载均衡功能;Web服务器无动外部IP地址,由反向代理服务器配置双网卡和内外两效IP地址。

图片 37

  1. 亮点:反向代理服务器功能集中,部署简单。

  2. 症结:反向代理服务器是兼具请求的响应的中转站,性能可能变成瓶颈。

IP负载均衡

1.
原理:负载均衡服务器114.10.80.10以操作系统内核进程取得网络数据包,根据负荷均衡算法计算得到平等雅Web服务器10.0.0.1,再将数据目的IP地址修改也10.0.0.1,无需用户进程处理;Web服务器10.0.0.1响应后,负载均衡服务器又将数据包源地址修改为自己IP地址114.10.80.10,发送给浏览器。

图片 38

2.
独到之处:在基础进程就数据分发,较反往代理负载均衡(应用程序分发)性能更好。

  1. 短:与反向代理负载均衡相同。
数链路层负载均衡

1.
原理:三角传输模式;直接路由于方(DR);负载均衡服务器就于数链路层修改目的MAC地址,配置真实物理服务器所有机器虚拟IP与负载均衡服务器IP地址一样,即可不改动数据包源地址及目的地址进行分发;真实物理服务器IP与数码要目的IP一致,无需通过负载均衡服务器即可响应数据返回浏览器。

图片 39

  1. 优点:避免负载均衡服务器成为瓶颈。

  2. 其实:大型网站使用最常见的负载均衡。Linux上最为好的开源产品是LVS(Linux
    Virtual Server)。

负载均衡算法
  1. 轮询(Round
    Robin,RR):所有请求依次分发到各级台服务器,适合所有服务器硬件都一样之情景。

  2. 加权轮询(Weight Round
    Robin,WRR):轮询基础及,按照部署的权重将请分发及各级令服务器,高性能的服务器分配更多请。

  3. 轻易(Random):请求随机分发到各国令服务器,也可加权随机。

  4. 起码连接(Least
    Connections):记录每台服务器在处理要(连接)数,将新请求分发及最少连接服务器,最适合负载均衡定义,也不过加权最少连接。

  5. 来自地址散列(Source
    Hashing):根据请求来源IP地址之Hash值,得到服务器,同一IP地址请求总在同样雅服务器上处理。

分布式缓存集群的紧缩性设计

1.
分布式缓存集群特点:集众多中每服务器数据不同,缓存访问请求不可以在自由一高处理,必须先行找到有缓存数据的服务器才能够看。

2.
分布式缓存集群访问原理:以写缓存Memcached为例,应用程序输入数据<‘BEIJING’,DATA>,API将KEY(‘BEIJING’)输入路由算法模块,路由于算法根据KEY和集群服务器列表计算得到一致令服务器编号NODE1和IP地址、端口;API调用通信模块将数据写入服务器NODE1。

图片 40

3.
分布式缓存的一致性Hash算法:可缓解伸缩性问题,但算法介绍Memcached且复杂,可能会见使Redis代替,以后再次看。

数码存储服务集群的紧缩性设计

关系数据库集群的伸缩性设计
  1. 主从复制:利用关系数据库数据复制功能,进行简短伸缩。

图片 41

2.
分库:不同工作数据表部署于不同数据库集群达。制约条件是超越库不能够join操作。

3.
分片:对某些单表数据量大之表(如Facebook用户表、淘宝商品表),将同张表拆分仓储于差不多只数据库。

    a) 比较成熟之支撑数据分片的开源分布式关系数据库产品:Amoeba、Cobar。

图片 42

    b)
分布式关系数据库特点:限制了关系数据库某些功能;海量数据压力只能采取分布式关系数据库伸缩。

    c)
分布式关系数据库注意:避免事务或应用工作上机制代替数据库事务;分解数据看逻辑避免join操作。

NoSQL数据库集群的伸缩性设计

NoSQL特点:放弃了关系数据库的以涉嫌代数为根基的结构化查询语言(SQL)和工作一致性保证(ACID),而强化大型网站关注的高可用性和可伸缩性。

扩展性

扩展性与伸缩性

1.
扩展性(Extensibility):对现有系统影响无与伦比小的气象下,系统机能而连扩展或提升的能力。

2.
伸缩性(Scalability):系统会由此多(减少)自身资源规模之方法加强(减少)自己计算处理事务的力量。

构建而扩大的网站架构

1.
企划网站可扩大架构的核心思想是模块化,并在这基础及下滑模块间的耦合性,提高模块复用性。

2.
模块化的基本点手段:分层和分,分层、分割为多独小耦合的独组件模块(模块可分布式部署,从情理上分别模块间耦合),各模块以消息传递及因调用方式聚合成完整系统。

以分布式消息队列降低系统耦合性

  1. 事件驱动架构(Event Driven
    Architecture):通过以没有耦合的模块之间传输事件信息,以维持模块的松散耦合,并赖事件信息的通信完成模块间协作。典型的EDA架构就是劳动者消费者模式。大型网站极度广大是分布式消息队列,利用发布/订阅模式工作。

  2. 分布式消息队列。

    a) 原理:前面章节已说明,不再赘述。

图片 43

    b)
伸缩性:新服务器在消息队列集群事,修改生产者服务器的音信队列服务器列表即可。

    c)
可用性:为避消费者进程处理缓慢、消息队列服务器内存不足等题材,如果内存队列已满,消息会受描绘副磁盘;为免信息队列服务器宕机,生产者服务器会保留消息直至信息确实给消费者服务器处理后才去,如果消息队列服务器宕机,生产者服务器会挑选分布式消息队列集众多中另外服务器发送。

    d) 开源Apache
ActiveMQ实现了可用性、伸缩性、数据一致性、性能与可管理性等。

应用分布式服务打造而复用的业务平台

1.
纵向拆分:将一个生用拆分为多只小应用,如果新增业务较为独立,那么直接配置为一个独门的Web应用。

2.
横向拆分:将复用的业务拆分,独立布置为分布式服务,新增业务就待调用这些分布式服务,无需依靠具体模块代码。

图片 44

  1. 不使用WebServices的理由:

    a) 臃肿的注册及发现体制;

    b) 低效的XML序列化手段;

    c) 开销比较高的HTTP远程通信;

    d) 复杂的配备及保障手段;

    e) 无法解决大型网站赛性能、高可用、易部署、易维护的求。

  1. 重型网站分布式服务的求跟特性:

    a) 注册与发现;

    b) 负载均衡

    c) 失效转移;

    d) 高效之长距离通信:核心服务每天调用次数数以亿计;

    e) 整合异构系统:服务或者用不同语言开发并部署不同平台;

    f) 对以最小寇;

    g)
版本管理:支持服务接口的多版本发布,方便服务调用者使用非升级之旧接口;

    h) 实时监控。

  1. 开源分布式服务框架:阿里巴巴Dubbo、Facebook Thrift。

图片 45

安全性

网站采取攻击与防卫

XSS攻击
  1. 攻击:即过站脚论攻击(Cross Site
    Script),攻击者通过篡改网页,注入恶意HTML脚本,在用户浏览器网页时,控制用户浏览器进行恶意操作。

    a) 反射型:攻击者诱使用户点击一个放到恶意脚本的连接,达到攻击目的。

图片 46

    b)
持久型:攻击者提交含有恶意脚本的伸手,保存于吃口诛笔伐的Web站点的数据库,用户浏览网页经常,恶意脚论给含有在例行网页中,达到攻击目的。

图片 47

  1. 防御。

    a)
消毒:对某些HTML危险字符转义,如“>”转义为“>”、“<”转义为“<”。

    b)
HttpOnly:浏览器禁止JavaScript访问带有HttpOnly属性的Cookie。无法防御XSS,但但防止XSS攻击者窃取Cookie。

流入攻击
  1. SQL攻击:攻击者在HTTP请求中注入恶意SQL(如drop table
    users),服务器用请求参数构造数据库SQL时,恶意SQL被联合实施。

图片 48

  1. 获取数据库表结构的手段。

    a) 开源:网站以开源软件(如Discuz!)搭建,已公开。

    b)
错误回显:如果网站被错误(服务器间500)回显,攻击者构造非法参数,使杀信息输出及浏览器。

    c)
盲注:如果网站关门错误回显,攻击者根据页面变化判断SQL执行情况,猜测表结构。

  1. 看守:使用预编译,绑定参数。

  2. 别注入攻击:OS命令、编程语言代码。

CSRF攻击
  1. 攻击:跨站请求伪造(Cross Site Request
    Forgery),攻击者通过跨站请求,以官方用户身份展开非法操作。核心是以浏览器Cookie或服务器Session盗取用户身份。

图片 49

  1. 防御。

    a)
表单Token:页面表单增加一个随意数作为Token,每次响应页面Token都不比,伪造之求无法得到Token,服务器检查该Token合法性。

    b) 验证码:请求提交时,需用户输入验证码,但验证码用户体验变差。

    c) Referer
check:HTTP请求头Referer记录请求来源,验证其合法性。很多网站采取该意义实现图片防盗链。

Web应用防火墙

ModSecurity是一个开源Web应用防火墙,既可停放Web应用服务器,也不过独立布置。最早是Apache一个模块,支持Nginx。

网站安全漏洞扫描

安全漏洞扫描工具根据内置规则,构造具有攻击性的URL请求,模拟攻击者攻击行为,以发现破绽。

信加密技术及密钥安全治本

徒为散列加密

1.
说明:通过对不同输入长度的音信进行散列计算,得到一定长度的输出,散列计算过程是一味为的,即未能够对固定长度输出进行计算获得输入信息。

图片 50

  1. 容:密码加密保存。

图片 51

  1. 泛算法:MD5、SHA。
对如加密
  1. 说:加密以及解密使用的密钥是暨一个密钥(或者可以彼此推算)。

图片 52

  1. 状况:信息需要安全交换或者存储的场所,如Cookie加密、通信加密。

  2. 亮点:加解密效率高,系统出小,适合大量多少加密。

  3. 周边算法:DES、RC。

切莫对如加密
  1. 诠释:加密与解密使用的密钥不是平密钥,一个公钥,一个私钥。

图片 53

  1. 情景:信息安全传输,数字签名场合。

  2. 大规模算法:RSA。

密钥安全治本

图片 54

  1. 应用程序调用加解密服务接口对信息加以解密。

2.
加解密服务接口通过密钥服务器获取加解密密钥,并缓存在该地(定时更新)。

3.
密钥服务器遭到之密钥来自多独密钥存储服务器,一个密钥分片后存储于差不多个存储服务器。

4.
密钥申请者、密钥管理者、安全审查人员经密钥管理控制台保管创新密钥,没有丁会查完的密钥。

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

秒杀活动的技艺挑战

1.
针对现有网站工作造成冲击:活动时不够、并发访问量大,如果与网站原有应用部署于一块,必然对现有工作冲击。

2.
胜并发下的用、数据库负载:秒杀开始前,用户不断刷新浏览器页面保证对了,请求而依一般网站以架构,会指向应用服务器、数据库服务器造成极大负载。

3.
赫然多的网络与服务器带富:假设秒杀页面大小200KB(主要是商品图片),那么所要带动富是200KB×10000=2GB。

  1. 一直下单:秒杀开始前,只能浏览,不同意下单。

秒杀系统架构设计

 图片 55

1.
秒杀系统独立布置:独立布置,甚至单独域名,使该及网站了切断,即使秒杀系统奔溃,也不影响网站。

2.
秒杀页面静态化:将货描述、商品参数、成交记录以及用户评价全部写副静态页面,请求无需访问应用服务器和数据库服务器。

3.
秒杀页面尽量简单:节约带富;用户关心能否上下单页面,而未是货物详情等用户体验细节。

4.
租赁秒杀网络带来富:向运营商重新进货或顶带富;秒杀页面缓存在CDN,需往CDN服务商临时租借新增出口带来富。

5.
动态变化随机下单页面URL:为免用户一直看下单页面URL,该URL必须动态化,在生单页面URL加入服务器生成的自由数作为参数,秒杀开始经常才能够获取。

6.
说了算秒杀页面购买按钮点亮:该页面引用包含是否开始和下单页面URL随机数的JavaScript文件,秒杀开始经常才大成该公文给浏览器加载。为逃避缓存,该公文于CDN、反向代理服务器缓存,并行使随机版本号。

图片 56

7.
但允许第一只提交的订单被发送到订单子系统:秒杀最终才出一个订单提交成功,为减轻服务器负荷,可决定只有个别用户(根据集群处理能力确定个数)能入下单页面,其他用户直接进去秒杀了页面。

图片 57

 

作者:netoxi
出处:http://www.cnblogs.com/netoxi
正文版权归作者和博客园共有,欢迎转载,未经允许要保留这个段子声明,且在篇章页面明显位置为有原文连接。欢迎指正与交流。

 

网站地图xml地图