《xx系统》的可用性和易用性

　　网站的可用性是一个网站的基础，要保证一个网站永远完全可用几乎是一件不可能完成的任务。

　（1）如何度量网站可用性？

　　一个神奇的数字—9！你有几个9，就代表了你的可用性。例如QQ可用性达到了4个9：99.99%

　　①2个9=基本可用　　②3个9=较高可用　　③4个9=具有自动恢复能力的高可用　　④5个9=极高可用->理想状态

　　那么，可用性的9又是怎么计算出来的呢：

　　①网站不可用时间=故障修复时间点-故障发现时间点

　　②网站年度可用性指标=（1-网站不可用时间/年度总时间）*100%

　　（2）如何考核网站可用性？

　　广泛采用故障分的，它是对网站故障进行分类加权计算故障责任的方法。一般会给每个分类的故障设置一个权重（例如事故级故障权重为100，A类为20等），其计算公式为：故障分=故障时间（分钟）*故障权重。公司对技术团队的考核一般会参考故障分，例如某团队今年发生了几个事故级故障，那么其绩效考核估计受到很大影响，年终奖什么的就悲剧了。

     

      Web应用中将上下文对象称为会话（Session），单机情况下由部署在服务器上得Web容器（如IIS、Tomcat、JBoss等）管理。在使用了负载均衡的集群环境中，由于请求的分发是随机的，所以保证每次请求依然能够获得正确的Session比单机时要复杂得多。

　　其次，我们来看看在集群环境中，Session管理的几种常见手段。

　　①Session复制：该方案简单易行，集群中的几台服务器之间同步Session对象，任何一台服务器宕机都不会导致Session对象的丢失，服务器也只需要从本机获取即可。但是，该方案只适合集群规模较小的情况下。当规模较大时，大量的Session复制操作会占用服务器和网络的大量资源，系统不堪重负。

      ②Session绑定：利用负载均衡的源地址Hash算法，总是将源于同一IP地址的请求分发到同一台服务器上。这样的话，在整个会话期间，用户所有的请求都在同一台服务器上进行处理，即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。（这种方案又叫做会话粘滞）。

但是，这种方案不符合高可用的需求。因为一旦某台服务器宕机，那么该机器上得Session也就不复存在了，用户请求切换到其他机器后因为没有Session而无法完成业务处理。因此，很少有网站采用此方案进行Session管理。

　　③Cookie记录Session：利用浏览器支持的Cookie记录Session简单易行，可用性高，并且支持服务器的线性伸缩，因此，许多网站都或多或少地使用了Cookie来记录Session。但是Cookie记录Session有缺点：比如受Cookie大小限制、每次请求响应都要传输Cookie影响性能、用户关闭了Cookie会造成访问不正常等。

      ④Session服务器：利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。这种方案实际上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。

      对于，有状态的Session服务器，一种较简单的方法是利用分布式缓存、数据库等，在这些产品的基础上进行封装，使其符合Session的存储和访问要求。