节点故障
网络故障
关于故障恢复策略,从单节点故障和网络故障两个维度展开。
对于单节点故障问题,往往采取主备策略,即当主节点故障后,从备节点中选出一个作为新的主节点,以继续提供服务。这种备升主的方式比较好理解。
如下图所示,用户 A 访问分布式集群时一直是与 Master 交互的,但当 Master 故障后,其他 Slave 会通过分布式选举算法选出一个新的主节点。假设,从 Slave 1、Slave 2 和 Slave 3 中选举出 Slave 2 作为新的 Master,则 Slave 2 需要承担原来 Master 的职责,继续为用户提供服务,因此当用户 A 再次访问集群时,提供服务的是新选出的 Master,也就是 Slave 2。这就是备升主的过程。
从用户 A 的角度来看,并不会感受到服务有什么异常,因为依旧可以正常访问集群。因此,主备策略可以大大提高分布式系统的可用性,在分布式系统中随处可见。比如Redis 集群、ZooKeeper 集群等,都是采用了这种主备策略来做故障恢复。
对于网络故障问题的解决方案,简单来说就是 C、A、P 选择的问题,即在分布式系统的可用性和数据一致性之间做权衡。根据不同的应用场景,选择不同的解决方案。
当分布式系统中出现网络故障时,对于高可用性要求严格的系统,比如要求必须及时响应用户的场景,就需要采用保 AP 弃 C 的策略;对于数据一致性有严格要求的系统,比如银行、金融系统等场景,就需要采用保 CP 弃 A 的策略。
网络故障恢复问题也可以看作数据复制的问题,即网络故障恢复后节点间数据同步的问题。
节点故障和网络故障也有交叉的地方,比如网络故障产生的原因可能是节点故障,即因为节点故障导致节点间无法通信,而不是纯粹的网络链路问题。这种情况有两种可能性,一种是节点临时性故障,即一段时间后就会恢复;一种是节点永久性故障,即节点不会恢复。针对第一种情况,只需等到故障恢复后,数据进行同步即可;第二种情况则需要备升主策略来解决。
知识扩展:固定心跳检测和基于历史心跳信息预测故障的策略,各有什么特点呢?
固定心跳检测的核心是,固定周期 T 秒发送心跳,若连续 k 次未收到心跳回复(时间 T 内),则判断心跳超时的时间为 kT 秒。可以看出,k 和 T 的设置非常重要。比如,对于要求秒级故障检测的场景(时延敏感性场景),则 kT≤1s,因此需要将 T 设置为 ms 级,比如200ms,k 设置为 1000/200=5 次。但,这样一来容易导致误判。因为判断超时的时间设置得太短,很可能是系统做内存回收或系统本身有高任务在运行导致心跳回复延后。对于时延不太敏感的场景,k 或 T 可以设置得大一些,降低误判率,但却会增加发现故障的时间。
φ值故障检测。φ值故障检测是基于心跳间隔符合正态分布的假设,通过对历史心跳数据采样来预测当前心跳是否超时的。也就是说,心跳间隔符合比较平稳或符合规律的情况下,比较适合,但对于具有突发情况或心跳间隔无规律的场景误判率比较高。
在网络状况确定且比较稳定的场景下,大多数系统会采用固定心跳检测策略,因为其可以根据网络状况与业务场景自主设定合适的 k 和 T 值,简单有效;而当网络状况有所变化,且变化有规律的场景,则可以使用φ值故障检测策略。
你知道的越多,你不知道的越多。