1 问题布景
在线下门店系统设备中，有好多方位需要使用Http请乞降第三方系统进行通讯，比如将门店的商品信息同步到第三方的电子价签上，再比如需要把门店伙计的打卡信息同步到公司使用的第三方EHR系统中。
但在使用Http申请外部管事时，由于会聚的不领会性，第三方接口出现超时的舒心时有发生，为了减少对业务酿成的影响，咱们垂死需要寻找一种Http重试决策。
2 重试决策探索
2.1 浅陋重试
咱们最容易猜想的一种重试神志是，在申请接口的代码块中加入轮回，要是申请失败则赓续申请，直到申请告捷或达到最大重试次数。示例代码如下：
这种重试神志相比浅陋，惟一申请发生相配就赓续重试，能在一定进程上料理咱们的问题，但污点是对于相配的拿获处理逻辑过于浅陋，重试起来会有一定的盲目性。
2.2 Apache HttpClient 重试机制
咱们常用的一些Http客户端平庸也内置了一些重试机制，接下来我将以咱们系统中使用的Apache HttpClient为例，通过手撕源码的神志探索一下它里面的重试机制。
平庸咱们在使用HttpClient的工夫，王人需要以下几个设施；
在创建 HttpClient 的过程中，底层调用了HttpClientBuilder的build要领，咱们奏凯找到跟重试相干的逻辑，源码如下图：
automaticRetriesDisabled默许是莫得禁用的，RetryExec是一个重试实验器，它还需要一个 RetryHandler，要是莫得指定的话，会使用DefaultHttpRequestRetryHandler动作默许的重试处理器。
咱们先来看一下RetryExec的逻辑，源码如下图：
看到这里，怎样还嗅觉到有点眼熟了呢？是不是和咱们上头浅陋重试的念念路是相通的呢，有点大路至简阿谁真理了。
咱们来浅陋转头一下RetryExec的主要逻辑：在实验Http申请的工夫，要是发生了IOException，会交给具体的RetryHandler来处理，然后由它的retryRequest要领来决定是赓续重试如故抛出相配。这里可能有的一又友会有疑问，为什么是IOException呢？
这就要说一下HttpClient的execute要领了，HttpClient实验时可能会抛出两种相配：IOException和ClientProtocolException；其中IOException被以为瑕瑜致命性且可收复的，而ClientProtocolException被以为是致命性的，不行收复，是以这里只需要关切IOException相配即可。
接下来咱们再来看一下DefaultHttpRequestRetryHandler，它界说了3个成员变量：
retryCount：重试次数；
requestSentRetryEnabled：是否不错在申请告捷发出后重试，这里的告捷是指发送告捷，并不指申请告捷；
nonRetriableClasses：不重试的相配类蚁集，要是相配为蚁集中指定的相配时，不会重试。
DefaultHttpRequestRetryHandler经过一系列构造函数，完成了对三个成员变量的赋值，其中默许的重试次数是3次，况且默许在申请发送告捷之后就不会再重试，默许的不重试相配有以下四类：
InterruptedIOException
UnknownHostException
ConnectException
SSLException
源码如下图：
然后，咱们再来看一下DefaultHttpRequestRetryHandler中的中枢要领retryRequest要领的逻辑，源码逻辑如下图：
retryRequest的逻辑也相比浅陋，最初升迁重试次数就不会再重试，然后要是是指定不重试的相配也不会再重试；再然后要是申请要领不是幂等的，也不会赓续重试，股票投资这里咱们谨慎的Post要领明白是不会进行重试的。不外还有契机，这里咱们知谈requestSentRetryEnabled默许是false，也即是说惟一申请发送告捷之后也不会进行重试。
到这里，咱们不错转头一下了。HttpClient默许的RetryHandler中指定了四类相配是不会进行重试的，其中就包含了InterruptedIOException，而实质上咱们连接会遭受的SocketTimeoutException就属于它的子类。
还有极少，要是按照默许的重试战略，明白Post申请也不孤高重试的要求。这里必须说一下，从严慎的角度来看，Post申请是否应该重试，需要具体会聚业务场景来看，要是申请本人不是幂等的，重试照实可能会带来严重的反作用。
是以在实质的业务场景中，要是想要愚弄HttpClient的重试机制来进行重试，这两个问题王人需要料理。
2.3 基于音问队伍的异步重试决策
有计划到在门店好多业务场景中，实验完相干的逻辑之后王人会发送MQ音问。那么咱们很当然地也猜想了通过引入一个奢华者的神志，来实验通过Http调用第三方接口的逻辑。
采用这种神志的话，要是在奢华逻辑中通过Http调用第三方接口失败，咱们还不错充分愚弄MQ的奢华失败重试机制。以咱们使用的RocketMQ为例，音问在奢华失败重试的工夫会按照一定的严防时辰来进行重试，这个特色还能幸免第三方管事因为短时辰的不行用而酿成的重试失败的情况。
3 门店业务场景中使用的重试决策
经过以上多种决策的调研，咱们最终采用的是决策二和决策三的轮廓决策，具体念念路如下。
最初，咱们全体的重试决策采用基于音问队伍的异步实验决策，一方面是因为这种决策不错充分地作念到和业务之间解耦，同期音问队伍的奢华失败重试机制不错很好地料理第三方管事短时辰不行用的问题，这极少是同步重试决策作念不到的，不错保险系统的最终一致性。
其次，因为咱们系统中依然在使用HttpClient 组件，是以咱们决定充分愚弄它的重试机制，同步重试也不错尽可能保证接口调用的实时性。
有计划到默许的重试战略不孤高咱们的使用需求，针对这个问题，咱们自界说了一个RetryHandler，源码如下图：
完成RetryHandler的自界说之后，只需要在运诊治HttpClient的工夫传入指定的RetryHandler即可，缔造神志如下：
这么咱们就料理了默许的重试机制对于Post申请默许不重试和SocketTimeoutException相配不重试的问题，愈加贴合咱们的使用场景。
这里我举个例子来讲明一下扫数这个词重试决策的实验经由：
MQ在奢华的工夫，会使用Apache HttpClient申请第三方接口，咱们缔造重试3次，要是申请一直失败，会先同步重试3次，要是如故失败，则本次音问奢华失败，恭候下一次重试音问赓续这个经由。
RocketMQ默许会重试16次，那么咱们扫数这个词重试决策会最多进行51次重试。
Apache HttpClient的同步重试能尽可能保证同步的实时性，而要是第三方管事出现短时辰不行用的舒心，RocketMQ的严防重试也能赓续异步重试只到最终告捷。
在咱们使用了这种重试决策之后，就再也莫得听到业务对于电子价签未实时同步简略打卡信息未同步的挟恨了。