网站可有效访问的特性。（不要挂）
硬件故障是常态，网站的高可用架构设计的主要目的就是：保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。
主要手段是数据和服务的冗余备份及失效转移。
大型网站的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。关闭服务或者服务器宕机时产生的影响也不相同，高可用的解决方案差异也大。典型的分层模型：
应用层
具体业务逻辑处理。
高并发，负载均衡设备通过心跳检测等监控，并进行失效转移处理
应用的一个显著特点是应用的无状态性：应用服务器不保存业务的上下文信息，仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等。
会话(Session)：多次请求修改使用的上下文对象。有状态。
集群环境下的Session管理：
**Session复制：**服务器之间同步Session对象。集群规模大时占用大量服务器和网络资源。
**Session绑定（会话黏滞）：**负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上，Session绑定在某台特定服务器上。
利用Cookie记录Session： Cookie大小限制、影响请求响应的性能、用户可能关闭Cookie
**Session服务器：**利用独立部署的Session服务器（集群）统一管理Session。实际是上将应用服务器按状态分离，分为无状态的应用服务器和有状态的Session服务器。可用性高、伸缩性好、性能好。
服务层
提供可复用的服务。
分布式服务调用框架实现负载均衡，并通过服务注册中心对提供服务的服务器进行心跳检测，修改服务访问列表
可复用的服务模块为业务产品提供基础公共服务，被具体应用远程调用。
无状态。因此可以使用类似负载均衡的失效转移策略实现高可用的服务。
其他策略：
- 分级管理
- 超时设置：在应用程序中设置服务调用的超时时间，防止响应超时的情况下占有应用程序的资源
- 异步调用
- 服务降级：在网站访问高峰期，为了保证核心应用和功能的正常运行，对低优先级的服务降级，拒绝服务及关闭服务。
- 幂等性设计：服务重复调用无法避免。因此需要服务层保证服务重复调用的结果相等
数据层
数据的存储与访问，如数据库服务，文件服务，缓存服务，搜索服务等。
保证数据存储高可用的手段主要是数据备份和失效转移机制。
缓存服务的高可用：
一种观点认为缓存事实上承担了业务中绝大多数的数据访问服务，因此需要实现和数据存储服务同样的高可用
另一种观点认为缓存服务不是数据存储服务，应该通过其他手段比如使用缓存服务器集群减小缓存服务器宕机引起的缓存失效影响
CPA原理：一个提供数据服务的存储系统无法同时满足数据一致性、数据可用性、分区耐受性这三个条件。
大型网站通常选择强化分布式存储系统的可用性和伸缩性，而在某种程度上放弃一致性。
数据强一致性：总是一致
数据用户一致：
数据最终一致：系统经过一段时间的自我恢复和修正，最终会达到一致
数据冷备：
系统存储损坏时，备份点之后的数据永久丢失，不能保证数据最终一致。
从冷备存储中恢复数据需要较长的时间，这段时间系统不可用，因此不能保证数据可用性。
数据热备：
异步热备方式：应用程序写成功一份，存储系统将会异步写其他副本。主从存储服务器。
同步方式：应用程序并发写入，多份数据副本的写入操作同步完成。存储服务器完全对等，更便于管理和维护。
数据服务器失效转移由三部分组成：
失效确认：通过心跳检测和应用程序访问失败报告进行确认。控制中心。
访问转移：将数据读写访问重新路由到其他服务器上。
数据恢复：系统从健康的服务器复制数据，将数据副本数目恢复到设定值。
高可用网站的软件质量保证
网站发布：分批发布集群中的一小部分服务，直到发布完成。
自动化测试
预发布验证：预发布服务器和线上正式服务器唯一的不同就是没有配置在负载均衡服务器上，外部用户无法访问。
代码控制：
自动化发布：网站火车发布模型。
灰度发布：网站灰度发布模型。
网站运行监控
广义上的监控涵盖所有非直接业务行为的数据采集与管理：
用户行为日志
服务器性能监控
运行数据报告
事物总是先求生存，然后求发展。