什么是高可用

[第二页 什么是高可用]

是指以减少服务中断时间为目的技术统称。它通过保护用户的业务程序对外不间断地提供服务，把因为软件，硬件，人为造成的故障对业务的影响降低到最小程度。总而言之就是保证公司业务7*24小时不宕机。

高可用的衡量标准

通常用平均无故障时间(MTTF：mean time to failure)来衡量系统的可靠性，用平均故障维修时间（MTTR：Mean Time Between Failures）来度量系统的可维护性。于是可用性被定义为： HA=MTTF/(MTTF+MTTR)*100%。

简单理解：如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。

衡量也受监测设备的局限，比如监测设备本身的故障、监测点的盲区、监测链路的网络故障等影响，不存在完美的衡量标准！

如何保障系统的高可用

[第三页 如何保障高可用]

我们都知道，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务肯定会受影响；如果有冗余备份，挂了还有其他backup能够顶上。

保证系统高可用，架构设计的核心准则是：冗余。

有了冗余之后，还不够，如果每次出现故障需要人工介入恢复势必会增加系统的不可服务时间。所以，又往往是通过“自动故障转移”来实现系统的高可用。

下面我们看看一般网站是如何做冗余的

[第四页 架构图]

图上是一个比较大型的网站架构图，可以看到里面大量使用到了分布式集群化部署，这种分布式集群化就是一种冗余架构。但是大部分中小网站目前还是采用单点形式，事实上分布式集群并不适合所有场景。

下面来想想看为什么？ （为什么分布式集群并不适合所有场景？）

[第五页 为什么分布式集群不适合所有场景？ ]

在网站初期考虑到人员、成本、项目复杂度等因素，一般会采用单点形式。

先来通俗解释一下什么是分布式：原本需要一个人干的事，现在分给n个人干！

但问题来了，既然分给了n个人，那就涉及到这些人的沟通交流协作问题。

如何来解决这些问题，就需要先聊聊分布式系统中的CAP理论。

CAP定理

[第六页 CAP理论 ]

我们先来了解一下这个理论产生的历史，CAP定理，也叫布鲁尔定理。

这个定理起源于加州大学柏克莱分校的计算机科学家埃里克·布鲁尔在2000年的分布式计算原理研讨会上提出的一个猜想。 在2002年，MIT麻省理工学院的赛斯·吉尔伯特 和 南希·林奇 发表了 布鲁尔猜想 的证明，使之成为一个定理。

事实上 吉尔伯特 和 林奇 证明的CAP定理比 布鲁尔 设想的某种程度上更加狭义。定理讨论了在两个互相矛盾的请求到达彼此连接不通的两个不同的分布式节点的时候的处理方案。

埃里克·布鲁尔是加州大学伯克利分校的终身教授。 1996年，布鲁尔创立了Inktomi公司（该公司开发了Traffic Server，这是一种代理服务器 Web缓存，用于万维网流量和按需流媒体，它们可以将图像转码为较小的尺寸，以供拨号Internet访问的用户使用。Traffic Server由包括AOL（American Online美国在线）在内的数家大型ISP部署。 在2003年互联网泡沫破灭之后，该公司以被2.41亿美元Yahoo!收购。）在2000年他与比尔·克林顿合作，他帮助创建USA.gov。在大约1990年代末的分布式网络应用中，他由于制定CAP定理而闻名。目前，他在谷歌任职。

下面我们来看看CAP定理

[第七页 CAP定理 ]

CAP定理指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

一致性

[第八页 一致性]

一致性，意思是写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。

接下来，用户的读操作就会得到 v1。这就叫一致性。

问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。

为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。

这样的话，用户向 G2 发起读操作，也能得到 v1。

可用性

可用性，意思是只要收到用户的请求，服务器就必须给出回应。

用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。

一致性和可用性的矛盾

[第九页 一致性和可用性的矛盾]

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。

如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。

综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

一致性和可用性权衡

【讨论1】在什么场合，可用性高于一致性？

CDN，新闻资讯，静态资源，搜索引擎。。。

【讨论2】在什么场合，一致性高于可用性？

电商订单，银行系统，证券金融系统，购票系统。。。

讨论完毕，就要引出BASE理论了

BASE理论

[第十页 BASE理论]

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

• 基本可用（basically available）：在分布式系统出现，允许损失部分可用性（服务降级、页面降级）
• 软状态（soft state）：允许分布式系统出现中间状态，而且中间状态不影响系统的可用性
• 最终一致性（Eventually consistent）：数据复制经过一段时间达到一致性

分布式系统是一个非常广泛的概念，它最终要落实到解决实际问题上，不同的问题有不同的方法和架构。

但如果以算法划分，到能分出几类：

比如经过严格数学证明的，分布式一致性算法paxos。

1.以Leader选举为主的分布式一致性算法，比如paxos、viewstamp，就是现在zookeeper、Chuby等工具的主体 2.以分布式事务为主的一类主要是二段提交，这些分布式数据库管理器及数据库都支持 3.以若一致性为主的，主要代表是Cassandra的W、R、N可调节的一致性 4.以租赁机制为主的，主要是一些分布式锁的概念，目前还没有看到纯粹“分布式”锁的实现 5.以失败探测为主的，主要是Gossip和phi失败探测算法，当然也包括简单的心跳 6.以弱一致性、因果一致性、顺序一致性为主的，开源尚不多，但大都应用在Linkedin、Twitter、Facebook等公司内部 7.以异步解耦为主的，有各类Queue

系统工程

[第十一页 系统工程]

前面扯了些理论的东西，要落实到实际工程领域，将有着很多系统性的挑战。

比如图上展示的：要保障高可用，我们需要从硬件、监测、运维、开发等多个领域去努力。

当然这将是一个非常大的课题，今天我们只粗浅的聊聊，在工程领域是如何保障高可用的。

硬件

[第十二页 硬件]

首先是硬件，在绝大部分系统架构中，都离不开3样硬件：防火墙、交换机、服务器。

防火墙

[第十三页 防火墙]

我们先看看防火墙，防火墙是保障系统架构安全可用性的重要屏障，阻挡大部分的黑客攻击是通过防火墙来实现的，防火墙分硬件防火墙和软件防火墙。

硬件防火墙常见的品牌，如图所示。如果做企业采购，我们一般从稳定可靠、 负载均衡、 双机热备、 优异性能、 售后支持这几个方面来考虑。

软件防火墙事实上有很多，大致分服务器级和用户终端级，早期还有专门的软件防火墙售卖，不过最近几年大多数操作系统都已集成性能不错的软件防火墙。

下面给大家演示一下Windows10里的防火墙配置。

交换机、路由器

[第十四页 交换机、路由器]

交换机和路由器，我们似乎经常接触，平常给我们感觉可能是同一样东西。因为家用级的路由器往往还有多个交换功能口。但在企业级网络中，这两者会用独立的硬件去处理。

常见的交换机、路由器品牌，如图所示。

这里我们要提一下，衡量交换机好坏，除了稳定性以外，还有个重要指标就是吞吐量。常见的百兆、千兆，企业级会用万兆、十万兆甚至更高。注意这里的兆是指兆比特。与我们通常理解的文件字节大小，要除以8来换算。

服务器

[第十五页 服务器]

服务器主要分大型机、小型机、X86架构服务器等，如图所示。

我们常用的当然是X86服务器。

在服务器领域，我们往往会遇到配置选择问题，如何去衡量一个服务器配置是否合理？

接下来就要引出一个概念：木桶效应

木桶效应

[第十六页 木桶效应]

木桶效应也称短板理论，原是管理学上的一个概念，想必大家都理解，当然它在硬件领域同样适用。

不过我们今天聊的是：反木桶效应！

如图所示，反木桶效应，就是在硬件性能出现瓶颈的地方，尽可能的通过软件去规避这种瓶颈。

比如我们常见的cache缓存，就是利用内存资源，去规避DiskIO上的性能瓶颈。

比如多线程，就是利用多核心来规避CPU主频的性能瓶颈。

这种体现在开发领域就是我们常说的性能优化。

性能优化也是我们今天重点讨论的问题，在开始这个问题前，我先提个问题。

一次访问经历了什么？

[第十七页 一次访问经历了什么]

我们来思考一个问题，用户访问一个网站到底经历了什么？如图。

请人回答。。。时间控制在3分钟！

HOSTS

[第十八页 HOSTS]

Hosts是我们经常忽视的一点，事实上输入URL后首先去找本地的Hosts文件，当Hosts里不存在，才会去请求DNS。

DNS

[第十九页 DNS]

DNS域名解析是互联网的根基，比如图上列表展示的是一些公共DNS。我们可以通过命令nslookup去手动查询DNS解析情况。

DNS劫持

[第二十页 DNS劫持]

全球的DNS网络是一项非常复杂的技术，这里就不展开了。

我们来聊一下DNS劫持，DNS劫持也叫域名劫持是互联网攻击的一种方式，通过攻击域名解析服务器（DNS），或伪造域名解析服务器（DNS）的方法，把目标网站域名解析到错误的地址从而实现劫持用户访问的目的。

我们可以从新闻媒体经常了解到，某某互联网公司网站被DNS劫持了，导致大量用户访问不了，或者被钓鱼攻击。比如：。。。

DNS高可用

[第21页 DNS轮询]

在高可用方面，DNS同样也做到了，比如我们可以为域名设置轮询，把用户访问导向最近的服务器IP上。如图所示。

DNS缓存

[第22页 DNS缓存]

DNS缓存也是一种高可用方案，我们访问网站的时候，系统会根据域名的配置，去自动缓存解析结果，通常会设定一个TTL缓存时间。

我们也可以通过命令去手动清除它。

[第23页 DNS缓存2]

如图所示，浏览器为了优化性能，也帮我们缓存了DNS解析数据。

网络质量

[第24页 网络质量]

解析完DNS，下一步要传输数据，传输数据的过程我们要关注：延迟、带宽、可用率等。

比如通过图上命令，去查看延迟、带宽。

[第25页 网络吞吐量]

我们可以通过如图所示的命令或工具来观察网络吞吐量等性能指标。

经过一系列的网络转发就到达我们服务器了。

运维与架构

[第26页 运维与架构]

运维

运维高可用主要体现在 故障发现机制 和 系统恢复机制。

故障发现机制比如：

报警的移动化

报警的实时化

监控的可视化

系统恢复机制比如：

回滚、重启、扩容、主备切换、集群迁移、异地容灾等等机制。

当然这些以后可以由我们运维工程师***为大家讲解。

架构

我们来看看架构这块，如图所示。如果大家理解了之前讲到的CAP定理和BASE理论，就能明白这张架构图的意义了。

比如，我们经常提到的动静分离，静态资源往往不会经常变动，而且是无状态的，所以适用于CAP定理中的AP，也就是高可用性。

像MySql集群，如果需要线程安全的场景，比如减库存，那么一定要保证一致性，也就是CAP定理中的CP。

像全文检索引擎 ElasticSearch，它的集群机制比如副本复制，故障迁移，就是基于BASE理论。

静态资源实现高可用最常见的就是部署CDN，但企业自己建设CDN往往成本巨大，一般都会选用一些专业的服务商，比如著名的CDN服务商cloudflare

[第27页 cloudflare]

事实上有很多CDN服务商，国内比较有名的有 阿里云、腾讯云、七牛云、新浪云、网宿科技、金山云等

[第26页 运维与架构]

图上所示的集群架构，需要大量的物理设备和人力维护成本，所以最近几年特别是中小企业，随着业务成本的考量，大家都从自建机房迁移到了云端。

[第28页 云计算]

高可用的低成本解决方案：

云计算的出现，让企业对高可用的需求渐渐摆脱了运维与人力的束缚，我们甚至可以通过几次点击很方便的用一个PAAS平台，来部署一个高可用网站。

现如今，比如我们公司，就使用了阿里云。

前面讲了些理论的东西，下面讲点实际工作中需要注意的优化项。

[第29页 如何做好高可用]

大家觉得自己工作中该如何做好高可用？

请大家回答，3分钟

下面从前端和后端讲讲，保障高可用的一些技术点：

前端：

后端：

数据库技术选型的时候面临：MySql、Mongodb如何抉择？

你期望一个更高的写负载

默认情况下，对比事务安全，MongoDB更关注高的插入速度。如果你需要加载大量低价值的业务数据，那么MongoDB将很适合你的用例。但是必须避免在要求高事务安全的情景下使用MongoDB，比如一个1000万的交易。

不可靠环境保证高可用性

设置副本集（主-从服务器设置）不仅方便而且很快，此外，使用MongoDB还可以快速、安全及自动化的实现节点（或数据中心）故障转移。

未来会有一个很大的规模

数据库扩展是非常有挑战性的，当单表格大小达到5-10GB时，MySQL表格性能会毫无疑问的降低。如果你需要分片并且分割你的数据库，MongoDB将很容易实现这一点。

使用基于位置的数据查询

MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。

非结构化数据的爆发增长

给RDBMS（关系数据库管理系统）增加列在有些情况下可能锁定整个数据库，或者增加负载从而导致性能下降，这个问题通常发生在表格大于1GB的情况下。鉴于MongoDB的弱数据结构模式，添加1个新字段不会对旧表格有任何影响，整个过程会非常快速；因此，在应用程序发生改变时，你不需要专门的1个DBA去修改数据库模式。

缺少专业的数据库管理员

如果你没有专业的DBA，同时你也不需要结构化你的数据及做join查询，MongoDB将会是你的首选。MongoDB非常适合类的持久化，类可以被序列化成JSON并储存在MongoDB。需要注意的是，如果期望获得一个更大的规模，你必须要了解一些最佳实践来避免走入误区。

[第42页 电商秒杀]

过年的时候正好遇到电商秒杀的业务需求，这里顺便聊聊。

秒杀活动将在较短时间内产生比平时大数十倍，上百倍的页面访问流量和下单请求流量。

秒杀活动可以分为3个阶段：

• 秒杀前：用户不断刷新商品详情页，页面请求达到瞬时峰值。
• 秒杀开始：用户点击秒杀按钮，下单请求达到瞬时峰值。
• 秒杀后：一部分成功下单的用户不断刷新订单或者产生退单操作，大部分用户继续刷新商品详情页等待退单机会。

消费者提交订单，一般做法是利用数据库的行级锁，只有抢到锁的请求可以进行库存查询和下单操作。但是在高并发的情况下，数据库无法承担如此大的请求，往往会使整个服务blocked阻塞，在消费者看来就是服务器宕机。

秒杀系统的流量虽然很高，但是实际有效流量是十分有限的。利用系统的层次结构，在每个阶段提前校验，拦截无效流量，可以减少大量无效的流量涌入数据库。

利用浏览器缓存和CDN抗压静态页面流量

秒杀前，用户不断刷新商品详情页，造成大量的页面请求。所以，我们需要把秒杀商品详情页与普通的商品详情页分开。对于秒杀商品详情页尽量将能静态化的元素静态化处理，除了秒杀按钮需要服务端进行动态判断，其他的静态数据可以缓存在浏览器和CDN上。这样，秒杀前刷新页面导致的流量进入服务端的流量只有很小的一部分。

利用读写分离Redis缓存拦截流量

CDN是第一级流量拦截，第二级流量拦截我们使用支持读写分离的Redis。在这一阶段我们主要读取数据，读写分离Redis能支持高达60万以上qps，完全可以支持需求。

[第43页 电商秒杀技术要点]

静态分离

前端处理

独立服务

限流

缓存

队列

分布式锁

作弊对抗

CC/DDOS攻击

并发测试

[第44页 总结如何做好高可用]

前端优化效果最好用户体验好

开发过程利用反木桶理论

数据库性能瓶颈重点关注

并发测试，覆盖测试

运维与监测