构建高可用的系统首先什么是高可用？“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

1.ha1.1避免单点。

负载均衡技术。

热备。

使用多机房1.2提高应用可用性1.2.1尽可能的避免故障1.2.2及时发现故障。

报警系统。

日志记录和分析系统1.2.3访问量和数据量不断上涨的应对策略。

水平伸缩。

拆分--1.应用拆分；2.拆分数据库；拆分表。

读写分离。

垂直伸缩。

其他以上高级知识点看了两遍觉得还是得继续修炼，毕竟实战经验很少。

------------------------------------------------------------------------计算机系统的可靠性用平均无故障时间(MTTF)来度量，即计算机系统平均能够正常运行多长时间，才会发生一次故障。

系统的可靠性能越高，平均无故障时间越长。

可维护性用平均维修时间(MTTR)来度量，即系统发生故障后维修和重新恢复正常运行平均花费时间。

系统的可维护性越好，平均维修时间越短。

计算机系统的可用性定义为：MTTF/(MTTF+MTTR)*100%。

举例来说，淘宝网在2010年成交额为300亿，则每分钟成交额为5—10万，那么对淘宝来说，其后台系统的高可用，对企业运营非常重要。

淘宝数据负责人宁海元指出，淘宝系统，可用性至少需要99.999%。

那么对于系统，在一年365天，系统停止服务时间为5分15秒。

高可用性的衡量指标可用性的计算公式：%availability=（Total Elapsed Time－Sum of Inoperative Times）/ Total Elapsed Timeelapsed time为operating time+downtime。

TotalElapsed Time 为系统总时间，包括可提供服务时间+停止服务时间。

Sumof Inoperative Times 为停止服务时间，包括宕机时间+维护时间。

可用性和系统组件的失败率相关。

衡量系统设备失败率的一个指标是“失败间隔平均时间”MTBF（mean time between failures）。

通常这个指标衡量系统的组件，如磁盘。

MTBF=Total Operating Time / Total No. of FailuresOperating time为系统在使用的时间（不包含停机情况）。

高可用性系统的设计计系统的可用性，最重要的是满足用户的需求。

系统的失败只有当其导致服务的失效性足以影响到系统用户的需求时才会影响其可用性的指标。

用户的敏感性决定于系统提供的应用。

例如，在一个能在1秒钟之内被修复的失败在一些联机事务处理系统中并不会被感知到，但如果是对于一个实时的科学计算应用系统，则是不可被接受的。

系统的高可用性设计决定于您的应用。

例如，如果几个小时的计划停机时间是可接受的，也许存储系统就不用设计为磁盘可热插拔的。

反之，你可能就应该采用可热插拔、热交换和镜像的磁盘系统。

所以涉及高可用系统需要考虑：决定业务中断的持续时间。

根据公式计算出的衡量HA的指标，可以得到一段时间内可以中断的时间。

但可能很大量的短时间中断是可以忍受的，而少量长时间的中断却是不可忍受的。

在统计中表明，造成非计划的宕机因素并非都是硬件问题。

硬件问题只占40%，软件问题占30%，人为因素占20%，环境因素占10%。

您的高可用性系统应该能尽可能地考虑到上述所有因素。

当出现业务中断时，尽快恢复的手段。

导致计划内的停机因素有：周期性的备份软件升级硬件扩充或维修系统配置更改数据更改导致计划外停机的因素有：硬件失败文件系统满错误内存溢出备份失败磁盘满供电失败网络失败应用失败自然灾害操作或管理失误通过有针对性的设计，可以避免上述全部或部分因素带来的损失。

当然，100%的高可用系统是不存在的。

创建高可用性的计算机系统在UNIX系统上创建高可用性计算机系统，业界的通行做法，也是非常有效的做法，就是采用群集系统（Cluster），将各个主机系统通过网络或其他手段有机地组成一个群体，共同对外提供服务。

创建群集系统，通过实现高可用性的软件将冗余的高可用性的硬件组件和软件组件组合起来，消除单点故障：消除供电的单点故障消除磁盘的单点故障消除SPU（System Process Unit）单点故障消除网络单点故障消除软件单点故障尽量消除单系统运行时的单点故障---------------------------------------------------1.2.1如何确保高可用（转载）可用性越高越好，提高可用性主要从一下几个方面入手：(1)系统架构(2)容灾性(3)监控报警(4)故障转移1.2.1.1 系统架构系统架构，指整个网站后台系统的架构。

好的系统架构，主要从下面几个方面考虑：(1)操作系统的选择，从稳定性、安全性和可维护性考虑，unix和linux性能远远好于windows，从成本考虑，Linux远远低于windows 和unix。

(2)负载均衡器的选择，硬件负载均衡器性能和稳定性高于软件负载均衡器。

但成本上，软件比如haproxy、LVS优于硬件(比如F5、Netscaler)。

(3)web server的选择，Nginx优于传统的Apache。

(4)各级缓存的选择与应用，varnish、squid、memcached。

(5)网站开发语言的选择，与开发有关，主要分为需要编译性的语言和不需要编译性的语言。

(6)数据库的选择，传统的关系数据库中，Oracle优于MySQL，但Oracle收费远远高于MySQL，实际上，Oracle有两种收费模式，一种是按用户数，一种是按主机处理器个数。

而MySQL 有免费的版本。

(7)底层存储设备的选择，比如机械磁盘和固态硬盘的选择。

(8)避免单点故障问题，在逻辑架构上，避免单点故障，避免出现割点。

1.2.1.2 容灾性容灾性能对系统非常重要，比如服务器因为断电，导致数据文件的不一致，因为发生自然或者非自然灾害比如火灾导致的磁盘损坏，发生数据丢失等。

所以容灾很重要，主要从以下几个方面提高容灾性能：(1)服务器热备机的部署，当发生故障后，热备机能马上使用，提供服务。

这里的服务器主要指web server 、应用服务器、数据库服务器等。

(2) 数据备份，比如做定期备份、热备份、增量备份，甚至需要做主从备份，来提高抗灾性能。

并且从底层存储设备上进行备份，比如做RAID。

(3) 做双线网络交换，尽量优化设计网络，避免因为核心交换机故障，而影响服务。

网络上避免单点故障。

1.2.1.3 监控报警监控是指对在线服务和非服务的在线服务器和相应的进程进行状态检测，当出现宕机或者某项服务进程僵死之后，能够在尽量短的时间获得该信息，然后通过报警系统将信息发送到一线运维人员。

所以，监控报警，直接影响宕机时间。

监控报警，主要从以下几个方面展开：(1) 监控主机CPU使用情况，负载情况。

(2) 监控主机内存使用情况。

(3) 监控主机IO外设，主要以磁盘为主。

如磁盘的读写、磁盘使用量等。

(4) 监控主机网卡使用情况。

网卡是否损坏，是否招到DDOS攻击。

(5) 监控应用进程，包括web server ，应用服务器等。

(6) 监控数据库使用情况。

包括用户的请求数、缓存使用量等。

(7) 监控交换设备的使用情况。

网络入、出的流量。

(8) 监控IDC机房温度、湿度等。

(9) 防火墙、入侵检测等安全检测、监控等。

通过上面的各项监控、得到相应数值，应用监控绘图软件，把相应的数值绘画出来，现有监控绘图软件有mrtg、cacti、nagios等。

然后设置一个报警阈值，如果超过该阈值，那么通过报警系统，比如短信、msn、邮件、甚至是声音完成报警功能。

典型的报警系统如图3-2-1-3所示。

图3-2-1-3如图3-2-1-3所示，监控服务器从servers上收集系统信息，如果发现系统的某项状态指数超过预设的阈值，则发送邮件到运维人员。

同时，把相应的报警信息发送到短信运营商的短信网关服务器，然后短信网关服务器发送短信到运维人员手机中，完成短信报警。

上述报警过程，传送邮件报警信息，是基于TCP/IP协议，而传送短信报警信息，是基于gprs网络。

1.2.1.4 故障转移故障转移是指，当对用户提供服务的服务器或者相应的应用进程发生故障后，比如服务器宕机、进程僵死之后，备用服务器能够在尽量短的时间内启用，提供服务。

这样能够最大限度减少损失，保证用户的正常服务。

所以，做好故障转移，要解决以下两个问题：(1) 实时监测故障问题。

(2) 准确快速切换服务器问题。

针对不同层次的服务，监测机制也不同，详细情况，在3.2.1.3已经阐述。

下面主要论述一下故障切换问题。

故障切换包括负载均衡器的故障切换、主机os的故障切换、web server的故障切换、应用进程的故障切换、数据库的故障切换、存储系统的故障切换、DNS的故障切换、交换设备的故障切换等。

下面主要分析进程僵死的故障转移和服务器宕机的故障转移。

进程僵死故障转移案例，常见的web server僵死故障转移如图3-2-1-4所示。

如图3-2-1-4-1所示，当主机172.29.141.112的web server 对外提供服务时，通过在主机172.29.141.113上部署监控程序Monitor_nginx.sh来监控主机172.29.141.112上面的web server进程运行情况，一旦发现172.29.141.112上web server停止服务，马上报警，先更改172.29.141.113的ip地址为172.29.141.112，再启用其自身的web server,完成故障转移。

此外，也可以在两服务器上同时部署监控程序Monitor_nginx.sh，完成互相监控。

服务器宕机故障转移案例，常见的服务器宕机故障转移，如图3-2-1-4-2所示。

图3-2-1-4-2如图3-2-1-4-2所示，服务器A和服务器B同时部署，但服务器A提供服务，而服务器B 作为热备机。

监控系统单独部署。

当服务器A宕机之后，监控系统会检测到这一信息，然后通过浮动更改服务器B的ip地址，完成故障切换。

1.3 本文小结本文主要阐述了网站后台系统的高可用性，分析了高可用性的定义和应用需求，重点阐述了如何做到高可用。

通过从不同应用级别，如主机、存储、网络、外设、数据库、安全等各个级别进行分析，最后详细论述了web server的故障转移和主机系统的故障转移。