HTTP 失败重试（重发）方案

已于 2025-03-19 10:41:58 修改
阅读量790 收藏 13
点赞数 17
分类专栏： Qt 文章标签： http 网络 qt
于 2025-03-19 10:26:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/m0_62573048/article/details/146362122
版权

   在 Qt 网络开发中，使用 QNetworkAccessManager 进行 HTTP 请求时，可能会遇到网络超时、服务器错误等情况。为了提高请求的可靠性，可以实现 HTTP 失败重试（重发） 机制。下面介绍几种常见的 失败重发方案：

单请求

1. 基本重试策略

适用于： 短暂的网络抖动、服务器瞬时不可用等情况。

实现思路：

  • 监听 QNetworkReply 的 finished() 信号，检查 error() 是否为失败状态。
  • 如果失败，等待一段时间后重新发送请求。
  • 设定 最大重试次数，避免无限循环重试。
  • #include <QCoreApplication>
#include <QNetworkAccessManager>
#include <QNetworkRequest>
#include <QNetworkReply>
#include <QTimer>
#include <QDebug>

class HttpRetryHandler : public QObject {
    Q_OBJECT
public:
    HttpRetryHandler(QObject *parent = nullptr)
        : QObject(parent), networkManager(new QNetworkAccessManager(this)), retryCount(0) {
        connect(networkManager, &QNetworkAccessManager::finished, this, &HttpRetryHandler::onReplyFinished);
    }

    void sendRequest() {
        QNetworkRequest request(QUrl("https://example.com/api"));
        request.setHeader(QNetworkRequest::ContentTypeHeader, "application/json");
        reply = networkManager->get(request);

        connect(reply, &QNetworkReply::finished, this, &HttpRetryHandler::onReplyFinished);
    }

private slots:
    void onReplyFinished() {
        if (reply->error() == QNetworkReply::NoError) {
            qDebug() << "Request successful:" << reply->readAll();
            reply->deleteLater();
        } else {
            qDebug() << "Request failed:" << reply->errorString();
            if (retryCount < maxRetries) {
                retryCount++;
                qDebug() << "Retrying..." << retryCount;
                QTimer::singleShot(retryInterval, this, &HttpRetryHandler::sendRequest);
            } else {
                qDebug() << "Max retries reached. Giving up.";
            }
        }
    }

private:
    QNetworkAccessManager *networkManager;
    QNetworkReply *reply;
    int retryCount;
    const int maxRetries = 3; // 最大重试次数
    const int retryInterval = 2000; // 失败后等待 2 秒再重试
};

int main(int argc, char *argv[]) {
    QCoreApplication a(argc, argv);
    HttpRetryHandler handler;
    handler.sendRequest();
    return a.exec();
}

#include "main.moc"

    关键点

  • 设置最大重试次数 (maxRetries)，避免无限重试。
  • 使用 QTimer::singleShot() 延迟重试，避免立即重试导致服务器压力增大。

2. 指数退避（Exponential Backoff）重试

适用于： API 速率限制、网络负载较高时的自动恢复。

实现思路：

  • 每次重试时，等待时间 指数增长（如 2^retryCount）。
  • 可以设置一个 最大等待时间，避免等待过长。
  • 适用于 API 限流（如 HTTP 429 Too Many Requests）或 服务器负载高的情况。
void retryWithBackoff() {
    if (retryCount < maxRetries) {
        int delay = qMin(initialRetryInterval * (1 << retryCount), maxRetryInterval);
        qDebug() << "Retrying in" << delay << "ms...";
        QTimer::singleShot(delay, this, &HttpRetryHandler::sendRequest);
        retryCount++;
    } else {
        qDebug() << "Max retries reached. Stopping.";
    }
}

关键点

  • 指数增长等待时间：delay = initialRetryInterval * (1 << retryCount)
  • 避免等待过长：使用 qMin() 限制最大重试间隔。

3. 仅对特定 HTTP 状态码重试

适用于：

  • 服务器错误（HTTP 5xx，如 500、502、503）。
  • 速率限制（HTTP 429 Too Many Requests）。
void onReplyFinished() {
    int statusCode = reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt();
    
    if (reply->error() == QNetworkReply::NoError) {
        qDebug() << "Success:" << reply->readAll();
    } else if (statusCode == 500 || statusCode == 502 || statusCode == 503 || statusCode == 429) {
        qDebug() << "Server error, retrying...";
        retryWithBackoff();
    } else {
        qDebug() << "Request failed permanently:" << reply->errorString();
    }
}

关键点

  • 避免对所有错误重试，只对 5xx/429 进行重试，减少无效请求。

4. 结合 QNetworkReply::redirected() 处理重定向

适用于： 遇到 301/302/307 重定向 时自动跟随新 URL。

void onReplyFinished() {
    QVariant redirectTarget = reply->attribute(QNetworkRequest::RedirectionTargetAttribute);
    if (!redirectTarget.isNull()) {
        QUrl newUrl = redirectTarget.toUrl();
        qDebug() << "Redirected to:" << newUrl;
        request.setUrl(newUrl);
        sendRequest();
        return;
    }
}

关键点

  • 检查 RedirectionTargetAttribute 并重新发起请求。

总结

方案适用情况优缺点
基本重试网络波动、短暂的服务器异常简单有效，但可能导致过多请求
指数退避API 限流、服务器负载高避免频繁请求，适应性更强
特定状态码重试5xx/429 错误只在必要时重试，减少无效请求
自动重定向301/302/307 响应处理 URL 变更，防止访问失败

在实际开发中，可以 结合多种策略：

  • 对 5xx/429 进行指数退避重试。
  • 对 301/302 自动重定向。
  • 对不可恢复错误（如 403/404）直接放弃。

多请求

如果有多个失败请求需要重试，可以使用 队列管理 机制来处理所有失败的请求，而不是单独重试每个请求。这可以确保 多个请求按顺序重试，并且不会让服务器负担过重。或者可以让请求并行。

方案 1：使用队列逐个重试

  • 适用于： 不希望所有请求同时重试，逐个处理失败请求，降低服务器压力。

实现思路：

  1. 维护一个 QQueue<QNetworkRequest> 队列，存储失败的请求。
  2. 失败请求会进入队列，并按照 FIFO（先进先出）顺序依次重试。
  3. 使用 QTimer 控制指数退避重试时间，依次出队并重试。
  4. 如果重试成功，从队列中移除请求，否则增加重试次数，重新排队。
#include <QCoreApplication>
#include <QNetworkAccessManager>
#include <QNetworkRequest>
#include <QNetworkReply>
#include <QTimer>
#include <QQueue>
#include <QDebug>
#include <QRandomGenerator>

class HttpRetryHandler : public QObject {
    Q_OBJECT
public:
    HttpRetryHandler(QObject *parent = nullptr)
        : QObject(parent), networkManager(new QNetworkAccessManager(this)) {
        connect(networkManager, &QNetworkAccessManager::finished, this, &HttpRetryHandler::onReplyFinished);
    }

    void sendRequest(const QUrl &url) {
        QNetworkRequest request(url);
        request.setHeader(QNetworkRequest::ContentTypeHeader, "application/json");
        QNetworkReply *reply = networkManager->get(request);

        requestMap.insert(reply, {request, 0}); // 记录请求和当前重试次数
        connect(reply, &QNetworkReply::finished, this, &HttpRetryHandler::onReplyFinished);
    }

private slots:
    void onReplyFinished() {
        QNetworkReply *reply = qobject_cast<QNetworkReply *>(sender());
        if (!reply) return;

        int statusCode = reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt();
        auto it = requestMap.find(reply);

        if (reply->error() == QNetworkReply::NoError) {
            qDebug() << "Request successful: " << reply->readAll();
            requestMap.remove(reply);
        } else if (statusCode == 500 || statusCode == 502 || statusCode == 503 || statusCode == 429) {
            // 服务器错误或限流，加入重试队列
            qDebug() << "Server error" << statusCode << ", adding request to retry queue...";
            retryQueue.enqueue(it.value());
            processRetryQueue();  // 处理队列
        } else {
            qDebug() << "Request failed permanently: " << reply->errorString();
        }

        reply->deleteLater();
    }

    void processRetryQueue() {
        if (retryQueue.isEmpty() || retrying) return;

        retrying = true;
        RequestData requestData = retryQueue.dequeue();

        if (requestData.retryCount < maxRetries) {
            int delay = qMin(initialRetryInterval * (1 << requestData.retryCount) + getJitter(), maxRetryInterval);
            qDebug() << "Retrying request in" << delay << "ms...";
            QTimer::singleShot(delay, this, [=]() {
                sendRequest(requestData.request.url());
                retrying = false;
                processRetryQueue();  // 继续处理下一个请求
            });
            requestData.retryCount++;
        } else {
            qDebug() << "Max retries reached for request: " << requestData.request.url();
            retrying = false;
        }
    }

private:
    struct RequestData {
        QNetworkRequest request;
        int retryCount;
    };

    QNetworkAccessManager *networkManager;
    QMap<QNetworkReply *, RequestData> requestMap;
    QQueue<RequestData> retryQueue;
    bool retrying = false;
    
    const int maxRetries = 5; // 最大重试次数
    const int initialRetryInterval = 1000; // 初始重试间隔 1 秒
    const int maxRetryInterval = 16000; // 最大重试间隔 16 秒

    int getJitter() { return QRandomGenerator::global()->bounded(500); } // 额外随机延迟 0~500ms
};

int main(int argc, char *argv[]) {
    QCoreApplication a(argc, argv);
    HttpRetryHandler handler;

    // 发送多个请求
    handler.sendRequest(QUrl("https://example.com/api1"));
    handler.sendRequest(QUrl("https://example.com/api2"));
    handler.sendRequest(QUrl("https://example.com/api3"));

    return a.exec();
}

#include "main.moc"

  关键点

(1) 多个请求失败后的处理
  • 使用 QMap<QNetworkReply *, RequestData> 记录请求信息
  • QQueue<RequestData> 存储失败的请求
  • processRetryQueue() 依次从队列取出请求并重试
(2) 防止所有请求同时重试
  • 使用 bool retrying 确保一次只处理一个重试请求
  • 指数退避 (2^retryCount) 并增加随机抖动
**(3) 重试失败的请求
  • 如果达到 maxRetries，则放弃重试
  • 否则等待 delay 时间后重试

方案 2：并行重试多个请求

如果你不想让请求 顺序重试，而是 并行重试多个请求，可以 使用多个 QTimer 并行调度，同时让多个请求进行指数退避重试。

void processRetryQueue() {
    while (!retryQueue.isEmpty()) {
        RequestData requestData = retryQueue.dequeue();

        if (requestData.retryCount < maxRetries) {
            int delay = qMin(initialRetryInterval * (1 << requestData.retryCount) + getJitter(), maxRetryInterval);
            qDebug() << "Retrying request to " << requestData.request.url() << " in " << delay << "ms...";

            QTimer::singleShot(delay, this, [=]() {
                sendRequest(requestData.request.url());
            });

            requestData.retryCount++;
        } else {
            qDebug() << "Max retries reached for request: " << requestData.request.url();
        }
    }
}

区别：

  • 多个请求可以同时重试（不会等待上一个重试完成）。
  • 所有请求仍然使用指数退避时间控制频率。

5. 结论

方案优点缺点
顺序重试（队列模式）减少服务器压力、保证请求顺序可能导致某些请求等待较久
并行重试（多定时器）提高吞吐量，适合高并发可能让服务器短时间内收到大量重试请求

 

 

注：本人也在学习中，如果有错误，请指出！！！

RT-DETR训练自己的数据集（从代码下载到实例测试）
Limiiiing的博客
09-14 1万+
在Windows10上配置CUDA环境教程是百度提出的一种实时目标检测模型。RT-DETR采用了与DETR相同的编码器和解码器结构，但对其进行了大量的优化，在保持较高检测精度的同时，实现了实时目标检测，为目标检测领域提供了一种新的有效解决方案，具有广泛的应用前景，如自动驾驶、智能监控、机器人等领域。以上是RT-DETR官方的论文和代码，详细介绍了RT-DETR的构成和实现。在YOLOv10中也实现了RT-DETR的代码，所以本文使用YOLOv10的项目文件进行RT-DETR的训练和测试。YOLOv10。
RT-DETR改进策略【Neck】| SEAM：分离和增强注意模块，解决复杂场景下的小目标遮挡问题
最新发布
Limiiiing的博客
04-17 297
本文记录的是利用 SEAM 模块优化 RT-DETR 的目标检测网络模型。的设计出发点在于解决复杂场景下的人脸遮挡问题，相当于是小目标被其他物体部分遮挡时，传统方法因特征缺失导致检测精度下降的问题。该模块通过增强未遮挡区域的特征响应并补偿被遮挡区域的信息损失，提升模型对遮挡小目标的检测能力。YOLO-FaceV2: A Scale and Occlusion Aware Face DetectorSEAM模块（Separated and Enhancement Attention Module）的设计出发点
RT-DETR代码详解（官方pytorch版）——参数配置（1）
小小老大MUTA的博客
01-07 6163
RT-DETR代码详解（官方pytorch版）参数配置
RT-DETR论文解读与代码
qq_52053775的博客
06-15 5634
目前以大名鼎鼎的YOLO为代表的基于CNN的实时监测网络需要NMS进行后处理，导致不能很好的优化网络，并且网络不够健壮，从而导致检测器的推理速度出现延迟。研究者也分析了Anchor-based和Anchor-free的YOLO的性能，发现Anchor并不是影响实时监测的关键要素，而NMS后处理彩色。DETR很好的解决了后处理对于模型的限制，却受限于Transformer巨大的计算量，无法发挥实时监测性。因此，作者想要重构detr,使其具有实时性。
RT-DETR改进策略【模型轻量化】| 替换骨干网络 CVPR-2024 RepViT 轻量级的Vision Transformers架构
Limiiiing的博客
12-03 461
一、本文介绍 本文记录的是基于RepVit的RT-DETR轻量化改进方法研究。RepVit的网络结构借鉴ViT的设计理念，通过分离的token mixe和channel mixer减少推理时的计算和内存成本，同时减少扩展比率并增加宽度，降低延迟，并通过加倍通道来弥补参数大幅减少的问题，提高了准确性。本文在替换骨干网络中配置了原论文中的repvit_m0_9、repvit_m1_0、repvit_m1_1、repvit_m1_5和repvit_m2_3五种模型，以满足不同的需求。 模型 参数量 计算量
RT-DETR模型源码解析
weixin_58429528的博客
08-07 1021
"""目的是将特定的函数（如 to(), cpu(), cuda(), half(), float() 等）应用到模型的张量上，但这些张量不能是模型的参数或已注册的缓冲区。'''举个例子，如果args = {'imgsz': 416, 'data': 'coco128.yaml', 'task': 'detect', 'batch_size': 8}，这里有一个明显的错误，'grfc' 很可能是一个拼写错误，应该是 'grpc'，这是一种常用于微服务架构的通信协议。
RT-DETR部分源码解析
weixin_58429528的博客
08-07 800
RT-DETR源码解析
RT-DETR详解之 Decoder 层
pengxiang1998的博客
06-11 3708
在上一篇博客中，博主已经讲解了如何利用选择出好的特征，接下来便要将这些特征输入到Decoder中进行解码，需要注意的是，在RT-DETR的Encoder中，使用的是标准的自注意力计算方法，而在其Decoder中，则使用的是可变形自注意力（deformable attention)，可变形自注意力能够大幅的降低计算量，同时该部分还使用到了CUDA算子，能够加快运行速度，当然，这个可变形自注意力计算并非是RT-DETR的创新点，但其作用却是极大，在DINO，DN-Deformable-DETR中都有使用。
RT-DETR推理详解及部署实现
周同学的博客
11-12 2万+
RT-DETR推理详解及部署实现
详解RT-DETR网络结构/数据集获取/环境搭建/训练/推理/验证/导出/部署
热门推荐
Snu77的博客
11-27 4万+
本文给大家带来是利用RT-DETR模训练自己的数据集，RT-DETR是一种新提出的目标检测模型，它利用的自注意力机制来处理图像数据。不同于YOLO通过连续的卷积层直接对图像区域进行分析，RT-DETR采用Transformer架构中的自注意力机制，这允许模型更有效地理解图像中不同部分之间的关系。这种方法使得RT-DETR在处理图像中的复杂场景和多对象环境时，能够展现出更高的准确性和效率。此外，RT-DETR在保持高精度的同时，也针对实时处理进行了优化，使其适合需要快速响应的应用场景。
RT-DETR改进有效系列目录 | 包含卷积、主干、RepC3、注意力机制、Neck上百种创新机制
Snu77的博客
01-29 2万+
Hello，各位读者们好Hello，各位读者，距离第一天发RT-DETR的博客已经过去了接近两个月，这段时间里我深入的研究了一下RT-DETR在ultralytics仓库的使用，旨在为大家解决为什么用v8的仓库训练的时候模型不收敛，精度差的离谱的问题，我也是成功的找到了解决方案，对于ultralytics仓库进行多处改进从而让其还原RT-DETR官方的实验环境从而达到一比一的效果。同时本人一些讲解视频和包含我所有创新的RT-DETR文档。
目标检测+PaddleDetection+rt-detr运行代码
06-28
该代码是百度的PaddleDetection代码，包含rt-detr配置文件和相关代码，可以直接用来测试
RT-DETR模型结构详解，在Ultralytics项目中配置rtdetr-resnet18、rtdetr-resnet34
Limiiiing的博客
01-21 1403
RT-DETR是一种实时端到端的目标检测模型，主要由 骨干网络、高效混合编码器和 带有辅助预测头的 Transformer 解码器组成。本文对其进行了详细分析，并在项目中配置了结构。
RT-DETR
weixin_65802479的博客
10-18 1167
RT-DETR 的网络架构是通过结合 CNN 和 Transformer 的优势，优化了目标检测流程，能够高效、准确地完成目标检测任务。其自注意力机制和特征融合技术使得模型能够处理复杂场景中的物体检测。
目标检测算法之RT-DETR
weixin_52862386的博客
06-27 3096
对RT-DETR的encoder部分，整体看下来像是yolo的backbone+neck。RT-DETR的核心还是在增速上，所以这里它的优化思想是值得借鉴的，但是yolo结构跟DETR结构之间的界限越来越模糊了。对query的优化上，只是做了对齐，使其选择的query更加精确。整体而言模型的创新不大。虽然DETR提倡的是NMS-Free，但是对于某些对精装度要求较高的任务中，如果阈值设置过低，导致最后得出的框过多，仍然需要借助NMS的方法去改进。设置过高则存在丢框的问题。
RT-DETR代码详解（官方pytorch版）——模型加载（2）
小小老大MUTA的博客
01-08 1648
找到在RT-DETR中，模型和数据集是怎么传入train_ine_epoch中进行训练的
[转]RT-DETR推理详解及部署实现-优快云博客
chinagudujian的专栏
01-04 4367
是由 Baidu 提出的基于 transformer 的端到端实时检测器，本篇文章主要分享博主在实现 RT-DETR 推理和部署时做的一些尝试，不涉及任何的原理性分析。若有问题欢迎各位看官批评指正😄博主在这里针对 RT-DETR 的预处理和后处理做了简单分析，同时与大家分享了 C++ 上的实现流程，目的是帮大家理清思路，更好的完成后续的部署工作😄。
RT-DETR：端到端的实时Transformer检测模型（目标检测+跟踪）
pengxiang1998的博客
05-31 8113
博主一直一来做的都是基于的目标检测领域，相较于基于卷积的目标检测方法，如YOLO等，其检测速度一直为人诟病。终于，RT-DETR横空出世，在取得高精度的同时，检测速度也大幅提升。那么RT-DETR是如何做到的呢？在研究RT-DETR的改进前，我们先来了解下DETR类目标检测方法的发展历程吧DETRNMSDAB-DETRDETR100DETRDAB-DETRH-DETR然而，上述方法尽管已经大幅提升了检测精度，降低了计算复杂度，但其受本身高计算复杂度的制约，DETR。
RT-DETR 基于Transformer的目标检测模型介绍及微调训练
小毕超博客
11-03 3480
RT-DETR是基于Transformer的目标检测模型,DETR的基础上采用了高效的混合编码器和IoU感知,有效降低了计算成本、提高了检测精度。
rt-detrv3网络结构
03-16
### RT-DETRv3 网络结构分析 RT-DETRv3 是一种基于 Transformer 的实时端到端目标检测算法，其核心在于通过引入分层密集正监督方法以及一系列创新性的训练策略，解决了传统 DETR 模型收敛慢和解码器训练不足的问题。以下是 RT-DETRv3 的主要网络结构特点： #### 1. **基于 CNN 的辅助分支** 为了增强编码器的特征表示能力，RT-DETRv3 引入了一个基于卷积神经网络 (CNN) 的辅助分支[^3]。这一分支提供了密集的监督信号，能够与原始解码器协同工作，从而提升整体性能。 ```python class AuxiliaryBranch(nn.Module): def __init__(self, in_channels, out_channels): super(AuxiliaryBranch, self).__init__() self.conv = nn.Conv2d(in_channels, out_channels, kernel_size=3, padding=1) self.bn = nn.BatchNorm2d(out_channels) def forward(self, x): return F.relu(self.bn(self.conv(x))) ``` 此部分的设计灵感来源于传统的 CNN 架构，例如 YOLO 系列中的 CSPNet 和 PAN 结构[^2]，这些技术被用来优化特征提取效率并减少计算开销。 --- #### 2. **自注意力扰动学习策略** 为解决解码器训练不足的问题，RT-DETRv3 提出了一种名为 *self-att 扰动* 的新学习策略。这种策略通过对多个查询组中阳性样本的标签分配进行多样化处理，有效增加了阳例的数量，进而提高了模型的学习能力和泛化性能。 具体实现方式是在训练过程中动态调整注意力权重分布，确保更多的高质量查询可以与真实标注 (Ground Truth) 进行匹配。 --- #### 3. **共享权重解编码器分支** 除了上述改进外，RT-DETRv3 还引入了一个共享权重的解编码器分支，专门用于提供密集的正向监督信号。这一设计不仅简化了模型架构，还显著降低了参数量和推理时间，使其更适合实时应用需求。 ```python class SharedDecoderEncoder(nn.Module): def __init__(self, d_model, nhead, num_layers): super(SharedDecoderEncoder, self).__init__() decoder_layer = nn.TransformerDecoderLayer(d_model=d_model, nhead=nhead) self.decoder = nn.TransformerDecoder(decoder_layer, num_layers=num_layers) def forward(self, tgt, memory): return self.decoder(tgt=tgt, memory=memory) ``` 通过这种方式，RT-DETRv3 实现了高效的目标检测流程，在保持高精度的同时大幅缩短了推理延迟。 --- #### 4. **与其他模型的关系** 值得一提的是，RT-DETRv3 并未完全抛弃经典的 CNN 技术，而是将其与 Transformer 结合起来形成混合架构[^4]。例如，它采用了 YOLO 系列中的 RepNCSP 模块替代冗余的多尺度自注意力层，从而减少了不必要的计算负担。 此外，RT-DETRv3 还借鉴了 DETR 的一对一匹配策略，并在此基础上进行了优化，进一步提升了小目标检测的能力。 --- ### 总结 综上所述，RT-DETRv3 的网络结构主要包括以下几个关键组件：基于 CNN 的辅助分支、自注意力扰动学习策略、共享权重解编码器分支以及混合编码器设计。这些技术创新共同推动了实时目标检测领域的发展，使其在复杂场景下的表现更加出色。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值