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了多少次还是失败。这种情况就是没有合理设置接口超时时间带来的问题。 

### HTTPRPC的特点应用场景 #### 一、概述 HTTP(Hypertext Transfer Protocol)是一种广泛使用的应用层协议,主要用于浏览器与服务器之间的数据交换。而RPC(Remote Procedure Call)则是远程过程调用的缩写,旨在让开发者像调用本地函数一样调用远程服务中的方法[^1]。 --- #### 二、HTTP的主要特点及优缺点 ##### 特点 - **普适性强**:几乎所有的编程语言都有内置的支持库来处理HTTP请求,这使得其成为跨平台通信的标准选择之一。 - **无状态性**:每一次请求都是独立完成的,不依赖前后的上下文关系,简化了缓存机制的设计[^2]。 - **易调试**:由于采用了明文形式的数据传输方式(尽管现在普遍加密),便于通过工具观察流量并排查错误。 - **丰富的生态系统**:得益于互联网的发展历程积累下来的经验教训,围绕着标准衍生出了众多成熟可靠的中间件产品服务[^3]。 ##### 优点 - 开发周期短,学习成本低; - 支持多种媒体类型,特别是JSON格式已经成为事实上的默认选项; - 天然具备良好的互操作能力,适合构建开放API接口供第三方接入使用。 ##### 缺点 - 相较于某些定制化的解决方案,在极端高性能需求面前可能存在瓶颈; - 默认情况下缺乏一些高级功能支持,例如自动重试失败的任务或是平滑切换不同版本的服务实例等操作[^4]。 --- #### 三、RPC的核心要素及其利弊分析 ##### 核心要点 - **透明度高**:隐藏掉底层网络细节之后,程序员只需关心业务逻辑本身即可,无需操心如何打包解包消息体等问题[^1]^。 - **高效的序列化方案**:相比起基于字符串解析的传统做法,现代RPC框架倾向于采用紧凑型二进制表示法来进行对象转换作业,从而减少带宽消耗提升吞吐量表现[^4]^。 - **集成更多辅助特性**:“开箱即用”的组件集合里通常包含了诸如负载均衡策略制定、超时控制设定等功能模块,有助于快速搭建健壮可用的基础架构体系^。 ##### 长处 - 提升程序间的交互效率,尤其是在大规模分布式环境下展现明显优势; - 更贴近实际编码习惯,降低心智负担; - 自动化程度较高,减少了人为干预带来的不确定性风险。 ##### 局限之处 - 存在一定的侵入性,可能会影响既有系统的稳定性; - 若选错实现路径,则可能导致后期维护困难; - 对新手不够友好,初次接触者需花费较多精力去理解背后原理[^2]^. --- #### 四、典型适用场景探讨 | 场景描述 | 推荐技术 | 理由 | |------------------------------|----------------|----------------------------------------------------------------------------------------| | Web前端到后端的一般性通讯 | HTTP | 方便快捷,易于与其他在线资源联动 | | 微服务之间高频次的小规模交流 | RPC | 减少不必要的开销,增强整体运行效能 | | 跨组织边界的公开服务平台建设 | REST over HTTP| 广泛接受度高,利于吸引外部贡献 | | 实时音视频流媒体分发 | WebSocket 或 gRPC| 前者保持持久连接通道后者兼顾速度质量 | --- #### 示例代码片段展示两种风格区别 以下是分别利用Python编写的一个简易版客户端发起GET请求的例子: ```python import requests response = requests.get('https://example.com/api/resource') print(response.json()) ``` 下面这段则演示了一个典型的gRPC调用情形: ```proto title="service.proto" syntax = "proto3"; package example; // The greeting service definition. service Greeter { // Sends a greeting rpc SayHello (HelloRequest) returns (HelloReply); } message HelloRequest { string name = 1; } message HelloReply { string message = 1; } ``` ```python from grpc import insecure_channel from generated_pb2_grpc import GreeterStub from generated_pb2 import HelloRequest channel = insecure_channel('localhost:50051') stub = GreeterStub(channel) request = HelloRequest(name='World') reply = stub.SayHello(request) print(reply.message) ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值