高可用的网站架构
实现高可用架构的主要手段是数据和服务的冗余备份以及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备用的磁盘中读取数据。
典型的网站架构主要分为三层：应用层，服务层，数据层。
以百度为例：
应用层主要部署了文库、贴吧、百科等产品服务
服务层主要部署了登录、百度账户等百度的通用可复用的服务
数据层主要部署了文件、数据库、缓存、搜索等数据服务
高可用的应用
无状态性：不保存业务上下文信息，请求到任意服务器得到的结果完全一样
1、 通过负载均衡进行无状态服务的失效转移
分发请求到各服务器处理，通过心跳检测发现某服务器失去响应，就将其从可用服务列表中删除
2、应用服务器的Session管理
- session复制： 服务器间同步session信息，适用于集群小的架构
- session绑定： 利用负载均衡源地址Hash算法将统一IP请求发送到同一台服务器上，但是服务器挂掉session就没了
- cookie记录session
- session服务器
高可用的服务
可复用的服务模块为业务产品提供了基础公共服务，大型网站中这些服务通常都独立分布式部署，被具体应用远程调用
分级管理
核心服务和应用优先使用更好的硬件设备超时设置
程序中设置服务调用超时时间，超时抛出异常，然后根据调度策略选择重试或者换一台服务器访问异步调用
应用对服务的调用通过消息队列等异步方式，避免一个服务失败导致整个应用请求失败的情况，但需要注意使用场景服务降级
大并发导致性能下降，服务降级的两种手段拒绝服务和 **关闭服务**。
**拒绝服务**： 拒绝低优先级的服务调用，确保核心应用正常或随机拒绝部分请求
**关闭服务**： 关闭部分不重要的服务以节约内存开销幂等性设置
保证服务重复调用和一次调用的一致性，避免因虚假失败（执行成功但是无响应）而产生的重复调用（比如转账）产生严重后果
高可用的数据
保证数据存储高可用的手段主要是数据备份和失效转移机制。
CAP原理
数据持久性
保证数据可持久存储，写入数据时备份多个副本数据可访问性
任何时候任意应用都能正常访问数据，一个设备损坏时，切换数据访问到可访问数据存储设备上数据一致性
保证多个副本之间的数据保持一致数据强一致：任何时候各个副本数据在物理存储中应该是一致的，数据操作结果和操作响应一致
数据用户一致：副本数据可能不一致，但用户访问时自动校验纠错可以返回一个一致而正确的数据
数据最终一致：用户访问可能不一致，但是系统经过一段时间修复和修正，最终达到一致
CAP原理认为一个存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Partition Tolerance，系统具有跨网络分区的伸缩性）。
一般在大型网站中会选择强化分布式存储系统的可用性（A）和伸缩性（P），在一定程度上放弃一致性。
数据备份
数据冷备不能保存数据最终一致，也不能保证数据可用性，但简单廉价
1、异步热备方式
应用程序连接其中一台数据服务器，数据写入时只写入连接数据库就响应成功，其他数据库通过异步线程或者消息队列同步数据
2、同步热备方式
多份数据副本写入操作同步完成，收到成功响应时数据全部同步成功，但如果失败，可能有部分副本已经成功
传统关系型数据库热备机制就是通常所说的主从同步机制，主从同步不仅解决了数据备份问题，还提高了数据库系统性能。
读写中常常使用读写分离访问，及写操作访问主数据库（Master），读操作访问从数据库（Slave）。
失效转移
如果服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不失败，这个过程就是失效转移。
失效转移主要分为三个部分：失效确认，访问转移、数据恢复。
1、失效确认
确认服务器是否宕机：心跳检测和应用程序访问失败报告。
对于应用的访问失败报告，控制中心需要再次发送心跳检测进行确认是否宕机，避免多副本数据不一致导致后续问题复杂化。
2、访问转移
完全对等服务器直接切换，不对等服务器重新计算路由然后选择存储服务器。
高可用的软件质量保证
1、网站发布
依次关闭集群中的小部分服务器同步更新然后重启。
2、自动化测试
开发自动化测试工具（如Selenium），一键部署，测试数据生成、测试执行、测试报告生成自动化完成。
3、预发布验证
现在预发布服务器上测试完成，再将代码同步到正式应用服务器上，预发布服务器与正式服务器仅载均衡配置有差异。
4、代码控制
代码版本控制工具：GIT、SVN等。
5、自动化发布
火车发布模型。根据响应驱动流程，自动化构造代码分支，进行代码合并，执行发布脚本等。
6、灰度发布
即每天发布一部分服务器，持续几天将整个集群全部发布，用来解决大型网站规模大不利于发生故障的时候及时回滚。