大型网站可用性

瞬时响应：网站的高性能架构

1. 网站性能测试：

    1). 不同视角下的网站性能

         a. 用户视角的网站性能：用户计算机，网站服务器通信时间，网站服务器处理时间，用户浏览器解析时间等。

         b. 开发人员视角的网站性能：

         c. 运维人员视角的网站性能：优化主干网，利用虚拟化技术优化资源利用等

    2). 性能测试指标

          a. 响应时间：单个请求时间不好计算，可以通过重复执行一万次，测试一万次执行需要的总响应时间之和，然后除以一万，得到单次请求的响应时间。

          b. 并发数：指系统同时处理请求的数目，这个数字也反映了系统的负载特性。测试程序通过多线程模拟并发用户的办法来测试系统的并发能力，为了模拟真实用户行为，测试程序并不是启动多线程然后不停

                         地发送请求，而是在两次之间加入一个随机等待时间，这个时间被称为思考时间。

          c. 吞吐量：单位时间内系统处理的请求数量，体现系统的整体处理能力。

          d. 性能计数器：描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络IO等指标。这些指标也是系统监控的重要参数，对这些指标设置报警阈值，

                               当监控系统发现性能计数器超过阈值时，就向运维和开发人员报警，及时发现处理系统异常。

    3). 性能测试方法：

         a. 性能测试：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到系能逾期。

         b. 负载测试：对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值，如某种资源已经呈饱和状态，这时继续对系统施加压力，系统的处理能力不但不能提高，反而下降。

         c. 压力测试：超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。

         e. 稳定性测试：被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，是系统运行一段较长时间，以此检测系统是否稳定。稳定性测试硬不均匀地对系统施加压力。

         f. 通过测试得出：网站日常运行区间，系统的最大负载点，系统的崩溃点

2.3 应用层集群的高可用

(1) 负载均衡进行失效转移

当负责负载均衡的反向代理服务器提高心跳检测机制发现集群中某一台服务器失去响应时，则将其移除，将请求转移到其他服务器上，提高了可用性。

(2) 集群的session管理

集群环境下，session管理要比单机时难的多，因为要想办法让每台服务器的session一样。一般有一下几种方法：

• session复制：一台服务器有某个session，就通过复制让所有服务器都有这个session。这种方法简单，但是数量大且改动频繁时会占用不少集群的通信资源。
• session绑定：通过负载均衡的源地址哈希算法实现，同一台客户机的请求总是落在同一台服务器，这样session就不需要同步到集群所有机器。但这样可用性低，当这台服务器宕机时，那台客户机的请求将会落到其他服务器，但此时其他服务器没有这客户机相关的session，一些相关的业务无法进行。这种方法很少用到。
• cookie记录状态信息，由客户端发送。这种方法无需session，自然没有了管理烦恼。但是cookie的大小受限、用户可能会将其关闭，传输影响性能，不够安全，因此也不能完全替代session。一般只有状态信息很小，安全性要求不高时用cookie。
• 如果不计较成本，比较好的方式是建立一个专门的session服务器，与无状态的应用服务器分离。应用服务器需要状态信息时都去请求这个session服务器。

• 负载均衡

  既然提到了集群，肯定得说说负载均衡。但是感觉负载均衡应该可以归类到可伸缩性里面去，所以这里就不详细讲啦，就简单说说有哪些常见的负载均衡的方式以及负载均衡算法。

  负载均衡方式

  • HTTP重定向负载均衡
  • DNS域名解析负载均衡
  • 反向代理负载均衡
  • IP负载均衡
  • 数据链路层负载均衡

  负载均衡算法

  • 轮询法
  • 随机法
  • 源地址哈希
  • 加权轮询
  • 加权随机
  • 最小连接数

  插播点别的

  突然想到一个比较有意思的东西：在微博的架构中，应该采用的是异步拉模型而不是同步推模型。什么意思呢？我们举个例子：鹿晗的粉丝有3000多万，关晓彤的粉丝有1000多万。假如他俩发了条微博的同时需要往这4000万粉丝的内容列表中(假设这里用的是关系型数据库)推送过去，这就是简化的同步推模型。

  那这样有什么缺点呢？首先，这样会消耗大量的数据库连接资源，更重要的是这样不太符合软件设计规范：因为对于两人的粉丝来说，分别由有3000多万和1000多万的数据是冗余的。假如说陈赫、邓超在第一时间对他俩的微博进行了点赞，此时瓶颈就来了：刚才往数据库里插入4000多万感觉还可以接受，但是现在四人的粉丝数加起来好几亿了，同时往数据库插这么多数据是不是感觉不太合适？

  没关系，我们现在换一种内容推送方式：我们现在不用同步推了，而是用异步拉。我们每次在手机上刷微博的时候，如果想要看到更新的内容是不是都要下拉刷新获取？没错这就是异步拉。异步拉有什么好处呢？很明显的一个好处就是可以将热点数据进行集中管理，并且不用进行大量的数据插入冗余操作。另外对系统资源的消耗也较少。那么微博内容从哪里拉呢？主流的解决方案是把热点内容放到缓存中，每次都去查缓存，这样可以减少I/O操作并且避免发生因资源枯竭造成的超时问题。