互联网容灾

【纲要】

常见事故及如何容灾

逻辑层容灾

数据层容灾

容灾判定

负载均衡，过载保护

【常见事故及如何容灾】

服务器故障死机  ------备份（硬件方案，软件方案）

服务雪崩------负载均衡，过载保护

网络环境恶劣------多运营商，异步部署就近服务

程序core，负责人无法联系 -----  自动拉起服务，备份负责人

...

【设计方案*逻辑层容灾】

*容灾模型

  1+1 容灾；1+n 容灾；n+1容灾

*切换方式主要有冷切，热切，双在线这三种方式

  冷切：

    主系统跑100%业务，备系统跑0%业务；当主系统出现问题，切到备系统；

    通用性；切换到备系统有一定的时间不能提供服务；并且备系统的可信度低

  热切：

    主备系统各跑一部分业务；主系统出现问题，业务全部由备系统提供服务；

    通用性，备系统可用性较高

  双在线：

    主备系统提供相同的服务，各跑100%业务

    专用性；备系统可用性高；流量高

【设计方案*数据层容灾】

  考虑恢复时间，采用1+n容灾

   主要有一个主机多个备机（中心化）和不分主备（完全分布式）两种方式

 *中心化

  采用快同步（增量同步）+ 慢同步（全量同步）的方式来保持数据一致性

 快同步：

    当有数据写入的时候，先写到主机上；再由主机同步到备机上；主机维护同步信息队列，同步信息列表，Binlog；主机的收到写消息后，会写一份到信息队列及binlog中；同步进程通过同步信息列表及同步信息队列获取信息，发送给备机（n个，n>=1）的写进程，并记录其写结果（成功，失败）;

 慢同步：

    主机的同步进程定时给备机发送数据信息验证码，通过备机返回的应答，确定需要传送的缺失数据

  同时需要监控，保证不能有两个中心节点

*去中心化（完全分布式）

  数据的一致性难以保证

  简单的案例(校验时间戳)

    在t1时刻，修改D1机器上的数据，发送同步数据包给D2

    在t2时刻，修改D2机器上的数据，发送同步包给D1

    在t3时刻，D2收到D1的同步数据包，发现时间戳比自己的小，丢弃数据

    在t4时刻，D1收到D2的同步数据包，校验时间通过，更新D1上的数据，如此，D1在t1时刻的修改就作废

 优化方式：给每个数据（或每组）添加一个时间戳，同步数据只校验数据本身的时间戳









    如上所述，分布式的数据存储在使用上确实不如中心化的便捷；但在某些场景下，却非常适用：数据有效性短

     a.) 频繁变化的最后一次操作,最后一次登录时间，IP等；

          在最遭的情况下，可以使用当前登录的时间，IP信息

     b.)  登录的通行证

          此场景下，可以在通行正中添加生成证书的服务器信息，在同步失败或其他原因引起的在提供服务器上找不到证书时，只要能解开通行证，取出生成的信息，即可到生成服务器上验证；在最糟的情况下，可重新登录，再生成新的通行证；

* R+W > N (Amazon的存储)

这个本人也是听的一头雾水，大概可以描述为：

当有5个数据节点时，设置写入成功的节点数为W时，那么在读时，成功的节点数达到R，满足R+W > 5，那么表示这个数据已经备正确读取，可以看下图：



当系统设计只需写3个数据节点便可认为数据写入成功，那么当我们去读取数据时，只要能至少从3个节点中读出数据便可认为已经读取数据成功。

以上述图为例：

3+3>5  均衡5+1>5  重写1+5>5  重读

【容灾判定】

 *中央判定 (TAF就是使用这种方式) 

    a. 服务上报心跳,确定服务状态 

    b. 状态中心主动探测 

    c. a+b结合 

   不足：服务质量无法验证

 *请求者判定 （如公司内的L5） 

    收集X时间片内服务对请求(用户的真实请求)的处理能力（时延，成功率等），相较中央判定方式其服务质量有一定的保证

【负载均衡】 

  * 接入负载 

     通过代理服务器（也可以是其他方式，DNS，NAT等）将请求转发给多台服务器处理； 

  * 号段负载 

      在有用户号的服务（主要指QQ号），如果只按1~n，n+1~2n这中方式来确定服务，可能造成某些服务负载过高，而有些却低负载；故可以采用散列方式来确定服务； 

  * 用户自助负载 

      就像游戏大厅那样，用户自己选择房间（服务器）

【过载保护】 

   频率控制，防雪球 

   服务必须清楚自己的处理能力，当超过处理能力或超时的请求直接拒绝丢弃