谈大规模分布式系统的可用性架构

一、应用层

1. 不保存状态

2. 通过负载均衡进行无状态服务失效转移，心跳检测

3. 集群的session管理：

a. session复制，通信量太大，已弃用；

b. session绑定，无法高可用，已弃用；

c. 浏览器cookie记录，大小受限，适用于信息量小的情况

d. session服务器，利用分布式缓存、数据库等手段进行包装。

常用的memcached来实现session共享。Memcached Session Manager 是一个比较有名的session共享插件。

Memcached Session Manager的实现原理

通过配置MemcachedSessionManager管理插件，来实现接替tomcat本身对于session的管理机制，从而实现共享session。

我们先看下msm的流程

MSM(memcached-session-manager)支持tomcat6和tomcat7及tomcat8，利用Value（Tomcat阀）对Request进行跟踪。Request请求到来时，从memcached加载session，Request请求结束时，将tomcat session更新至memcached，以达到session共享之目的，支持sticky和non-sticky模式。

黏性Session：此模式下同一会话中的请求都被派送到同一个tomcat实例上，这样我们就无须在多台服务器之间实现session共享了，这是其好处，不好的地方就是不能实现failureover了，一但用户访问的机器挂掉，那么其session就会丢失。

非黏性Session：又名复制Session，此模式下同一会话中的请求可以被分配到不同的tomcat实例上进行处理，此时就需要在不同服务器之间同步、复制session，这样一来即使一台服务器挂掉了，请求在其它服务器上照样可以访问到session信息，其缺点在于Session复制需要系统资源和网络开销。

之前在项目中遇到一个情况是，3台web server配置了有2台memcached组成的集群作为session服务器集群，访问的session值总是在变。后来检查发现是Tomcat的配置文件里memcachedNodes="n1:IP地址:端口"  只写了一个memcached服务器造成的。

二、服务层

1. 分级管理：高低优先级服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离；

2. 超时设置：设置服务调用的超时时间，超时后重试或者请求转移；

3. 异步调用：通过消息队列等方式避免一个服务失败导致整个应用请求失败；

4. 服务降级：并发量太大时可通过关闭服务或者拒绝访问，保证高优先级任务正常进行；

5. 幂等性设计：通过信息校验等手段保证不会出现重复调用。

三、数据层

保证数据存储高可用的主要手段是数据备份和失效转移。

整个网站共享一个缓存集群，通过分区方式将每个应用缓存部署在多个服务器上。

CAP原理：一致性、可用性、持久性。通常选择可用性和持久性，放弃强一致性。

数据备份：

a. 异步热备：主存储服务器写入数据后立即返回，异步线程将数据同步到从存储服务器。

b. 同步热备：同时写入多个存储服务器，都成功后才返回。

失效转移：某台数据服务器宕机后，针对这台服务器的所有读写操作都需要重新路由到其他服务器。

失效转移由3步组成。

a. 失效确认：通过心跳服务确认访问失败；

b. 访问转移：对于对等服务器直接切换，对于不对等服务器需要重新计算路由；

c. 数据恢复：从健康的服务器复制数据，将数据副本数目恢复到设定值。

四、可用性的软件保证

在网站发布过程中也要保证网站的可用性，可以采用

1. 发布到预发布服务器上验证；

2. 灰度发布

五、监控

1. 采集监控数据

a. 收集用户行为日志

b. 服务器性能监控

c. 运行数据报告

2. 报警、自动失效转移、自动降级