假如这是第二次看到我的文章，欢迎订阅z哥的公众号（跨界架构师）哦~

本文长度为4229字，建议阅读11分钟。

坚持原创，每一篇都是用心之作～

这是本系列中既「数据一致性」后的第二章节——「高可用」的完结篇。

前面几篇中z哥跟你聊了聊做「高可用」的意义，以及如何做「负载均衡」和「高可用三剑客」（熔断、限流、降级，文末会附上前文连接：））。这次，我们来聊一聊在保证对外高可用的同时，憋出的“内伤”该如何通过「补偿」机制来自行消化。

一、「补偿」机制的意义？

以电商的购物场景为例：

用户端 —->购物车微服务 —->订单微服务 —-> 支付微服务。

这种调用链非常普遍。

那么为什么需要考虑补偿机制呢？

正如之前几篇文章所说，一次跨机器的通信可能会经过DNS 服务，网卡、交换机、路由器、负载均衡等设施，这些设施都不肯定是一直稳固的，在数据传输的整个过程中，只需任意一个环节出错，都会导致问题的产生。

而在分布式场景中，一个完整的业务又是由屡次跨机器通信组成的，所以产生问题的概率成倍数添加。

但是，这些问题并不完全代表真正的系统无法解决请求，所以我们应当尽可能的自动消化掉这些异常。

可能你会问，之前也看到过「补偿」和「事务补偿」或者者「重试」，它们之间的关系是什么？

你其实可以不用太纠结这些名字，从目的来说都是一样的。就是一旦某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。

题外话：在Z哥看来，不论用什么方式，只需通过额外的方式处理了问题都可以了解为是「补偿」，所以「事务补偿」和「重试」都是「补偿」的子集。前者是一个逆向操作，然后者则是一个正向操作。

只是从结果来看，两者的意义不同。「事务补偿」意味着“放弃”，当前操作必然会失败。

▲事务补偿

「重试」则还有解决成功的机会。这两种方式分别适用于不同的场景。

▲重试

由于「补偿」已经是一个额外流程了，既然能够走这个额外流程，说明时效性并不是第一考虑的因素，所以做补偿的核心要点是：宁可慢，不可错。

因而，不要草率的就确定了补偿的实施方案，需要谨慎的评估。虽说错误无法100%避免，但是抱着这样的一个心态或者多或者少可以减少少量错误的发生。

二、「补偿」该怎样做？

做「补偿」的主流方式就前面提到的「事务补偿」和「重试」，以下会被称作「回滚」和「重试」。

我们先来聊聊「回滚」。相比「重试」，它逻辑上更简单少量。

「回滚」

Z哥将回滚分为2种模式，一种叫「显式回滚」（调用逆向接口），一种叫「隐式回滚」（无需调用逆向接口）。

最常见的就是「显式回滚」。这个方案无非就是做2个事情：

首先要确定失败的步骤和状态，从而确定需要回滚的范围。一个业务的流程，往往在设计之初就制定好了，所以确定回滚的范围比较容易。但这里唯一需要注意的一点就是：假如在一个业务解决中涉及到的服务并不是都提供了「回滚接口」，那么在编排服务时应该把提供「回滚接口」的服务放在前面，这样当后面的工作服务错误时还有机会「回滚」。

其次要能提供「回滚」操作使用到的业务数据。「回滚」时提供的数据越多，越有益于程序的健壮性。由于程序可以在收到「回滚」操作的时候可以做业务的检查，比方检查账户能否相等，金额能否一致等等。

因为这个中间状态的数据结构和数据大小并不固定，所以Z哥建议你在实现这点的时候可以将相关的数据序列化成一个json，而后存放到一个nosql类型的存储中。

「隐式回滚」相对来说运用场景比较少。它意味着这个回滚动作你不需要进行额外解决，下游服务内部有相似“预占”并且“超时失效”的机制的。例如：

电商场景中，会将订单中的商品先预占库存，等待客户在 15 分钟内支付。假如没有收到客户的支付，则释放库存。

下面聊聊可以有很多玩法，也更容易陷入坑里的「重试」。

「重试」?

「重试」最大的好处在于，业务系统可以不需要提供「逆向接口」，这是一个对长期开发成本特别大的利好，毕竟业务是天天在变的。所以，在可能的情况下，应该优先考虑使用「重试」。

不过，相比「回滚」来说「重试」的适用场景更少少量，所以我们第一步首先要判断，当前场景能否适合「重试」。比方：

????■?下游系统返回「请求超时」、「被限流中」等临时状态的时候，我们可以考虑重试

????■?而假如是返回“余额不足”、“无权限”等明确无法继续的业务性错误的时候就不需要重试了

????■?少量中间件或者者rpc框架中返回Http503、404等没有何时恢复的预期的时候，也不需要重试

假如确定要进行「重试」，我们还需要选定一个合适的「重试策略」。主流的「重试策略」主要是以下几种。

策略1.立即重试。有时故障是候暂时性，可能是因网络数据包冲突或者硬件组件流量高峰等事件造成的。在此情况下，适合立即重试操作。不过，立即重试次数不应超过一次，假如立即重试失败，应改用其它的策略。

策略2.固定间隔。应用程序每次尝试的间隔时间相同。 这个好了解，例如，固定每 3 秒重试操作。（以下所有示例代码中的具体的数字仅供参考。）

策略1和策略2多用于前台系统的交互式操作中。

策略3.增量间隔。每一次的重试间隔时间增量递增。比方，第一次0秒、第二次3秒、第三次6秒，9、12、15这样。

return (retryCount – 1) * incrementInterval;

使得失败次数越多的重试请求优先级排到越后面，给新进入的重试请求让道。

策略4.指数间隔。每一次的重试间隔呈指数级添加。和增量间隔“异曲同工”，都是想让失败次数越多的重试请求优先级排到越后面，只不过这个方案的增长幅度更大少量。

return 2 ^ retryCount;

策略5.全抖动。在递增的基础上，添加随机性（可以把其中的指数增长部分替换成增量增长。）。适用于将某一时刻集中产生的大量重试请求进行压力分散的场景。

return random(0 , 2 ^ retryCount);

策略6.等抖动。在「指数间隔」和「全抖动」之间寻求一个中庸的方案，降低随机性的作用。适用场景和「全抖动」一样。

var baseNum = 2 ^ retryCount;

return baseNum + random(0, baseNum);

3、4、5、6策略的体现情况大致是这样。(x轴为重试次数)

为什么说「重试」有坑呢？

正如前面聊到的那样，出于对开发成本考虑，你在做「重试」的时候可能是复用的常规调用的接口。那么此时就不得不提一个「幂等性」问题。?

假如实现「重试」选用的技术方案不能100%确保不会重复发起重试，那么「幂等性」问题是一个必需要考虑的问题。哪怕技术方案可以确保100%不会重复发起重试，出于对意外情况的考量，尽量也考虑一下「幂等性」问题。

幂等性：不论对程序发起几次重复调用，程序体现的状态（所有相关的数据变化）与调用一次的结果是一致的话，就是保证了幂等性。

这意味着可以根据需要重复或者重试操作，而不会导致意外的影响。对于非幂等操作，算法可能必需跟踪操作能否已经执行。

所以，一旦某个功能支持「重试」，那么整个链路上的接口都需要考虑幂等性问题，不能由于服务的屡次调用而导致业务数据的累计添加或者减少。

满足「幂等性」其实就是需要想办法识别重复的请求，并且将其过滤掉。思路就是：

? ? 1. 给每个请求定义一个唯一标识。

? ? 2. 在进行「重试」的时候判断这个请求能否已经被执行或者者正在被执行，假如是则抛弃该请求。

第1点，我们可以使用一个全局唯一id生成器或者者生成服务（可以扩展阅读，分布式系统中的必备良药 —— 全局唯一单据号生成）。 或者者简单粗暴少量，使用官方类库自带的Guid、uuid之类的也行。

而后通过rpc框架在发起调用的用户端中，对每个请求添加一个唯一标识的字段进行赋值。

第2点，我们可以在服务端通过Aop的方式切入到实际的解决逻辑代码之前和之后，一起配合做验证。

大致的代码思路如下。

【方法执行前】

if(isExistLog(requestId)){//1.判断请求能否已被接收过。? 对应序号3

????var lastResult = getLastResult();//2.获取用于判断之前的请求能否已经解决完成。? 对应序号4

????if(lastResult ==null){?

? ? ? ? var result = waitResult();//挂起等待解决完成return result;

? ? }

? ? else{

? ? ? ? return lastResult;

? ? }?

}

else{

? ? log(requestId);? //3.记录该请求已接收

}

//do something..

【方法执行后】

logResult(requestId, result);? //4.将结果也升级一下。

假如「补偿」这个工作是通过MQ来进行的话，这事即可以直接在对接MQ所封装的SDK中做。在生产端赋值全局唯一标识，在消费端通过唯一标识消重。

三、「重试」的最佳实践

再聊少量Z哥积累的最佳实践吧（划重点：）），都是针对「重试」的，确实这也是工作中最常用的方案。

「重试」特别适合在高负载情况下被「降级」，当然也应当受到「限流」和「熔断」机制的影响。当「重试」的“矛”与「限流」和「熔断」的“盾”搭配使用，效果才是最好。

需要衡量添加补偿机制的投入产出比。少量不是很重要的问题时，应该「快速失败」而不是「重试」。

过度积极的重试策略（例如间隔太短或者重试次数过多）会对下游服务造成不利影响，这点肯定要注意。

肯定要给「重试」制定一个终止策略。

当回滚的过程很困难或者代价很大的情况下，可以接受很长的间隔及大量的重试次数，DDD中经常被提到的「saga」模式其实也是这样的思路。不过，前提是不会由于保留或者锁定稀缺资源而阻止其余操作（比方1、2、3、4、5几个串行操作。因为2一直没解决完成导致3、4、5没法继续进行）。

四、总结

这篇我们先聊了下做「补偿」的意义，以及做补偿的2个方式「回滚」和「重试」的实现思路。

而后，提示你要注意「重试」的时候需要考虑幂等性问题，并且z哥也给出了一个处理思路。

最后，分享了几个z哥总结的针对「重试」的最佳实践。

希望对你有所帮助。

Question：

你之前有哪些时候是通过自己人工来做「补偿」的经历吗？欢迎吐槽～

z哥自己就有屡次熬到半夜才把“意外”造成的混乱清除干净，刻骨铭心啊??。

相关文章：

分布式系统关注点——初识「高可用」

分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的

分布式系统关注点——「负载均衡」究竟该如何实施？

分布式系统关注点——做了「负载均衡」即可以随意加机器了吗？这三招来帮你！

分布式系统关注点——99%的人都能看懂的「熔断」以及最佳实践

分布式系统关注点——想通关「限流」？只需这一篇

分布式系统关注点——让你的系统“坚挺不倒”的最后一个大招——「降级」

分布式系统中的必备良药 —— 全局唯一单据号生成

? 关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。本文首发于公众号：「跨界架构师」（ID：Zachary_ZF）。

假如你是初级程序员，想提升但不知道如何下手。又或者者做程序员多年，陷入了少量瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

假如你是经营，面对不断变化的市场束手无策。又或者者想理解主流的经营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「经营」，送你一份我长期收集和整理的思维导图。

定期发表原创内容：架构设计丨分布式系统丨产品丨经营丨少量深度思考。