本文主要分析网站的高可用性，从应用需求、用户角度展开分析。
1.1 高可用性
“高可用性”(High Availability) 通常用来描述一个系统，经过特殊设计，减少停止服务的时间，从而使其服务保持高度的可使用性。
计算机系统的可靠性用平均无故障时间(MTTF)来度量，即计算机系统平均能够正常运行多长时间，才会发生一次故障。系统的可靠性能越高，平均无故障时间越长。可维护性用平均维修时间(MTTR)来度量，即系统发生故障后维修和重新恢复正常运行平均花费时间。系统的可维护性越好，平均维修时间越短。计算机系统的可用性定义为：MTTF/(MTTF+MTTR)*100%。
举例来说，淘宝网在2010年成交额为300亿，则每分钟成交额为5—10万，那么对淘宝来说，其后台系统的高可用，对企业运营非常重要。淘宝数据负责人宁海元指出，淘宝系统，可用性至少需要99.999%。那么对于taobao.com系统，在一年365天，系统停止服务时间为5分15秒。
1.2 确保高可用性
高可用性的衡量指标
%availability=(TotalElapsed Time – Sum of Inoperative Times) / Total Elapsed Time
其中：
TotalElapsed Time 为系统总时间，包括可提供服务时间+停止服务时间。
Sumof Inoperative Times 为停止服务时间，包括宕机时间+维护时间。
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
如图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的故障转移和主机系统的故障转移。