Http和Rpc重试机制

重试机制定义：

重试机制是在设置的超时时间到了之后没有返回结果或者服务端出现异常后服务调用端进行再次调用。

首先，不是所有接口都适合重试，如果一个服务是不等幂，那么不适合重试的机制，因为会存在重复提交的问题，否则是可以进行重试的。比如提交一个订单的接口是不能进行重试的，而把订单信息推给wms系统接口是可以重试的。

一般两个部署在不同网段的系统不能通过dubbo的rpc调用，只能用最原始的http调用，比如在占用库存的时候调用库存中心或者将配送信息推送给wms时，由于网络的波动或者商品数量多导致处理时间长等原因，需要对调用接口进行重试，具体代码如下：

private final int MAX_RETRY = 4;
int retries = 1;
JSONObject jsonObject = null;
do {
    long startTime = System.currentTimeMillis();
    jsonObject = HttpServer.httpPostFormEntity(url, params, httpClient);
    long endTime = System.currentTimeMillis();
    float seconds = (endTime - startTime) / 1000F;
    logger.info(order_id + "=== 执行时间:" + seconds + "s");
    logger.info(order_id + "=== 推送订单到wms出参:{}", new Object[]{jsonObject});
    if (jsonObject.get("returnCode").equals("0")) {
        long waitTime = DateHelper.getWaitTime(retries);
        try {
            Thread.sleep(waitTime);
        } catch (InterruptedException e) {
            logger.error("Error", e);
        }
    } else {
        return jsonObject;
    }
} while (retries++ < MAX_RETRY);
return jsonObject;

//waitTime按幂重试
public static long getWaitTime(int retryTime) {
    long waitTime = (long)Math.pow(2.0D, (double)retryTime) * 1000L;
    return waitTime;
}

以上是http调用的重试机制，比较简单。

DUBBO通过rpc调用时消费端设置额超时时间不能随心所欲，需要根据业务实际情况来设定，太短导致在设定的超时时间内无法完成正常的业务处理。太长的话会造成进程假死。就是所有的进程都在等待状态。

当消费端达到超时时间，dubbo会进行重试机制（如果配置了dubbo.reference.retries>1），重试机制大于1次会给服务提供端带来压力，而压力是正常值*dubbo.reference.retries倍，最终dubbo的消费端会出现RpcException提示retry了多少次还是失败。这种情况就是没有合理设置接口超时时间带来的问题。