架构基础3-网站的高可用

实现高可用架构的主要手段是数据和服务的冗余备份 及 失效转移

典型的分层模型是三层：应用层，服务层，数据层。各层之间具有相对独立性，中小型网站在具体部署时，通常将应用层和服务层部署在一起，数据层另外部署，大型网站划分的粒度会更小，更复杂。

应用层服务层数据层

应用层：主要负责具体业务逻辑处理

服务层：负责提供可复用的服务，例如注册登录服务，session管理服务等公共的服务

数据层：负责数据的存储与访问

应用层的高可用：

应用层也叫业务逻辑层，特点是应用的无状态性，指应用服务器不保存业务的上下文信息，仅根据每次请求提交的数据进行业务逻辑处理。多个服务器之间完全对等。

应用层高可用策略是通过负载均衡进行无状态服务的失效转移。

应用服务器集群的Session管理：

1，session复制：web容器开启session复制功能，使集群中每台服务器同步session，保存所有用户的session。但复制占用服务器和网络的大量资源，不适合大型网站。

2，session绑定：利用负载均衡的源地址Hash算法，将同一IP的请求分发到同一台服务器，这时候的负载均衡器必须工作在HTTP协议层上。但当某一台服务器挂了，Session也会丢失，因此这种方法也很少使用。

3，利用Cookie记录session：这种方法受cookie大小限制，而且浏览器不能禁用cookie，不常用，但session较小的情况下也可以使用。

4，session服务器集群：可以利用分布式缓存，数据库等记录session,应用服务器从中取得。如果需要做SSO等，则需要开发专门的Session管理平台。推荐使用此方法。

服务层的高可用：

1，分级管理：核心应用分离部署，避免连锁反应。

2，超时设置：应用程序对服务端调用如果失去响应，用户请求就长时间得不到响应，同时还占用应用程序的资源，所以在应用程序中设置服务调用的超时时间。一旦超时，应用程序可选择重试或转换到其它服务器上。

3，异步调用：应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。

4，服务降级：访问高峰时，为保证核心应用可用需要对服务进行降级，两种降级手段：拒绝服务和关闭服务。

5，幂等设计：保证应用调用服务时调一次和调多次产生的结果是一样的，保证服务的幂等性。

数据层的高可用：

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据的一致性（Consistency）,数据可用性（Availibility）,分区耐受性（Partition Tolerance）。

保证数据高可用的策略是数据备份和失效转移

1，数据备份：

冷备方式：定期将将数据进行备份，不能保证数据最终的一致性，而且从冷备数据中恢复需要时间，不能保证数据可用性。

热备方式：分为异步和同步两种方式，mysql的主从备份就是默认异步备份，数据可能还未成功写入从服务器就已经返回。但也提供同步热备的方式，通常也会通过应用程序对数据端进行多写。这种方式意味着存储服务器的响应时间不是多台存储服务器响应延迟之和，性能和异步热备方式差不多。

2，失效转移：

系统确认一台服务器是否可用有两种手段：心跳检测和应用程序访问失败报告。