失败模式

在分布式架构中, 如SOA或者微服务架构,你不能担保服务调用如你所预想的一样好。有时候服务会宕机、网络被挖断、网络变慢等,所以你需要容忍这些状况。

rpcx支持四种调用失败模式,用来处理服务调用失败后的处理逻辑, 你可以在创建XClient的时候设置它。

FailMode的设置仅仅对同步调用有效(XClient.Call), 异步调用用,这个参数是无意义的。

Failfast

示例: failfast

在这种模式下, 一旦调用一个节点失败, rpcx立即会返回错误。 注意这个错误不是业务上的 Error, 业务上服务端返回的Error应该正常返回给客户端,这里的错误可能是网络错误或者服务异常。

Failover

示例: failover

在这种模式下, rpcx如果遇到错误,它会尝试调用另外一个节点, 直到服务节点能正常返回信息,或者达到最大的重试次数。 重试测试Retries在参数Option中设置, 缺省设置为3。

Failtry

示例: failtry

在这种模式下, rpcx如果调用一个节点的服务出现错误, 它也会尝试,但是还是选择这个节点进行重试, 直到节点正常返回数据或者达到最大重试次数。

Failbackup

示例: failbackup

在这种模式下, 如果服务节点在一定的时间内不返回结果, rpcx客户端会发送相同的请求到另外一个节点, 只要这两个节点有一个返回, rpcx就算调用成功。

这个设定的时间配置在 Option.BackupLatency 参数中。

这种通过资源换取延迟的方式可以参看 Jeff Dean的文章 Achieving Rapid Response Times in Large Online Services

From http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html Backup requests are the idea of sending requests out to multiple replicas, but in a particular way. Here’s the example for a read operation for a distributed file system client:

send request to first replica wait 2 ms, and send to second replica servers cancel request on other replica when starting read A request could wait in a queue stuck behind an expensive query or a packet could be dropped, so if a reply is not returned quickly other replicas are tried. Responses come back faster if requests sit in multiple queues.

By smallnest            updated 2019-07-12 13:36:32

results matching ""

    No results matching ""