服务器集群容错是什么

本文主要讲解“什么是服务器集群容错”，感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“什么是服务器集群容错”！

集群容错:集群服务调用失败后，服务框架需要能够在底层自动容错。容错策略有很多，适合不同的场景。下面将详细描述集群容错的功能和设计。

1、集群容错场景

在分布式服务框架中，业务消费者不需要知道服务提供商的具体位置，其发起的呼叫请求不包含服务提供商的具体地址信息。因此，对于消费者来说，服务提供商是否可用并不重要，但最终服务呼叫的成功才是最重要的。

在服务路由之后，为远程呼叫选择服务提供商，但是服务呼叫可能出错。以下是对可能的故障场景的分析。

1.1、通信链路故障

这里的链路指的是消费者和服务提供商之间的链路(通常是长连接)，由于以下原因可能导致链路中断

1)通信过程中，对方突然宕机，导致链路中断。

2)通信过程中，对方因解码失败等原因使连接停止，导致链路中断。

3)通信过程中，消费者的写SocketChannel发生IOException，导致链路中断。

4)通信过程中，消费者读取SocketChannel发生IOException，导致链接中断。

5)通信方因检测到心跳超时主动关闭套接字通道，导致链路中断。

6)通信过程中，网络出现闪断。

7)通信过程中，交换机异常导致链路中断。

8)在沟通过程中，消费者或服务商由于长期Full GC而失去联系。

无论是什么原因导致链路中断，该服务呼叫都将失败。

1.2、服务端超时

当服务器无法在指定时间内向客户端返回响应时，将发生超时。超时的主要原因是：

1)服务器I/O线程没有及时从网络读取客户端请求消息，通常是因为I/O线程不小心被阻塞或执行了长时间的操作而导致问题。

2)服务器业务处理缓慢或长时间阻塞，如查询数据库，由于没有索引，整个表查询耗时较长。

3)服务器长时间发生全GC，导致所有业务线程停止运行，未能及时向客户端返回响应。

1.3、服务端调用失败

有时会发生服务器端调用失败，造成服务器端调用失败的原因主要有几个：

（=NationalBureauofStandards）国家标准局

p;  1）、服务端解码失败，会返回消息解码失败异常。
            2）、服务端发生动态流控，返回流控异常。
            3）、服务消息队列积压率超过最大阈值，返回系统拥塞异常。
            4）、访问权限校验失败，返回权限相关异常。
            5）、违反SLA(Service-Level Agreement:服务等级协议)策略，返回SLA控制相关异常。
            6）、其他系统异常。
        需要指出的是服务调用异常不包括业务方面的处理异常，例如数据库异常、用户记录不存在异常等。

2、容错策略

    服务不同，容错策略也往往不同。下面看看集群容错和路由策略之间的关系。如图1-1所示：
     
                                        图1-1：集群容错和服务路由的关系

    消费者根据配置的路由策略选择某个目标地址之后，发起远程服务调用，在此期间如果发生远程服务调用异常，则需要框架进行集群容错，重新进行选路和调用，集群容错是系统自动执行的，上层用户并不关心底层的服务调用过程。

    2.1、失败自动切换（Failover）

        服务调用失败自动切换策略指的是当发生RPC调用异常时，重新选路，查找下一个可用的服务提供者。

        服务发布的时候，可以指定服务的集群容错策略。消费者可以覆盖服务提供者的通用配置，实现个性化的容错策略。

        Failover策略的设计思路如下：消费者路由操作完成之后，获得目标地址，调用通信框架的消息发送接口发送请求，监听服务端应答。如果返回的结果时RPC调用异常（超时、流控、解码失败等系统异常），根据消费者集群容错的策略进行容错路由，如果是Failover，则重新返回到路由Handler的入口，从路由节点继续执行。选路完成之后，对目标地址进行对比，防止重新路由到故障服务节点，过滤掉上次的故障服务提供者之后，调用通信框架的消息发送接口发送请求消息。

        分布式服务框架提供Failover容错策略，但是用户在使用时需要自己保证用对地方，下面对应用场景进行总结：
            1）、读操作，因为通常它是幂等的。
            2）、幂等性服务，保证调用1次与N次效果相同。
        需要特别指出的是，失败重试会增加服务调用时延，因此框架必须对失败重试的最大数做限制，通常默认为3，防止无限制重试导致服务调用时延不可控。

    2.2、失败通知（Failback）

        很多业务场景中，消费者需要能够获取到服务调用失败的具体信息，通过对失败错误码等异常信息的判断，决定后续的执行策略，例如非幂等性服务调用。

        Failback的设计方案如下：服务框架获取到服务提供者返回的RPC异常响应之后，根据策略进行容错。如果是Failback模式，则不再重试其他服务提供者，而是将RPC异常通知给消费者，由消费者捕获异常进行后续处理。

    2.3、失败缓存（Failcache）

        Failcache策略是失败自动恢复的一种，在实际开发中应用场景如下：
            √ 服务状态路由，必须定点发送到指定的服务提供者。当发生链路中断、流控等服务暂时不可用时，服务框架将消息暂时缓存起来，等待周期T，重新发送，回到服务提供者能够正常处理该消息。
             √ 对时延要求不敏感的服务。系统服务调用失败，通常是链路暂时不可用、服务流控、GC挂住服务提供者进程等，这种失败不是永久性的，他的失败是可预期的。如果消费者调用对时延不敏感，可以考虑使用自动恢复模式。既先缓存、再等待、最后重试。
             √ 通知类服务。对服务调用的实时性不高，可以容忍自动恢复带来的时延增长。

        为了保证可靠性，Failcache策略在设计的时候需要考虑如下几个要素：

              √ 缓存时间、缓存对象上限数等需要做出限制，防止内存溢出。
              √ 缓存淘汰算法的选择，是否支持用户配置。
              √ 定时重试的周期T，重试的最大次数等需要做出限制并支持用户指定。

    2.4、快速失败（Failfast）

        在业务高峰期，对于一些非核心的服务，希望只调用一次，失败也不再重试，为重要的核心服务节约宝贵的运行资源。此时快速失败是个不错的选择。

        快速失败策略设计简单，获取到服务异常之后，直接忽略异常，记录异常日志。

    2.5、容错策略扩展

        无论服务框架支持多少种容错策略，业务在实际使用过程中一定会有不适应的地方，通过开放容错策略接口的方式，可以支持用户自定义扩展容错策略。

        在集群容错设计的时候，需要考虑扩展性，主要从以下几方面进行设计：

            1）、容错接口的开放。
            2）、屏蔽底层细节，用户定制简单。
            3）、配置应当支持扩展，不要让用户扩展服务框架Schema。

到此，相信大家对“服务器集群容错是什么”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！