为何长连接gRPC流在循环重连时启动缓慢？

我正在实现一个基于长连接gRPC流的后端推送通知方案：客户端订阅特定通知后，后端会在事件发生时实时推送通知，RPC会保持活跃直到客户端退出（服务端不调用Finish()）。后端与客户端运行在同一机器上，网络延迟可忽略。

为支持客户端先于后端启动的场景，我让客户端每0.5秒尝试订阅一次，核心代码如下：

std::string server_addr = "unix-abstract:test";
auto client = MakeClient(server_addr);

while (!TryToSubscribeNotifications(client));

订阅成功则退出循环，否则重试：

bool
TryToSubscribeNotifications(Client &client)
{
using std::chrono_literals::operator""ms;

std::thread(&Client::SubscribeNotifications, &client).detach();
std::this_thread::sleep_for(500ms);

return client.IsSubscribed();
}

客户端内部用atomic_bool维护订阅状态，IsSubscribed()直接返回该状态值。

核心问题 #

若客户端先于后端启动约一分钟，后端启动后客户端无法立即完成订阅，而是需要等待一段随机时间（最长约30秒）才能成功建立连接。

复现步骤 #

• 仅启动客户端，不启动后端；
• 等待一分钟，客户端会每0.5秒打印Notification rpc failed. Attempt #；
• 启动后端；
• 客户端仍会在随机时间（通常≤30秒）内无法建立连接。

我使用的是gRPC C++回调式异步API，环境信息：

• Fedora 36
• gcc 12.2.1
• protobuf 3.21.6.0
• gRPC 1.49.1

原因分析 #

问题源于手动重试逻辑与gRPC内置连接退避机制的冲突：

1. gRPC内置指数退避策略：当客户端多次连接失败后，gRPC会自动启用指数退避，不再按你设置的0.5秒间隔重试，而是逐渐拉长重试间隔，最长可达30秒左右。你每次重试都创建新线程发起订阅的方式，会不断触发gRPC的退避判断，导致后续连接尝试被强制延迟。
2. 线程与状态检查的竞态：TryToSubscribeNotifications中启动线程后直接sleep 500ms再检查状态，但gRPC异步回调可能还未完成状态更新，或连接尝试已被退避机制延迟，导致你误判订阅失败，进而创建更多重试线程，加剧退避触发。

解决方案 #

1. 复用gRPC通道，将重试逻辑移至异步回调内 #

不要每次重试都创建新客户端/线程，复用同一个gRPC通道，让客户端在连接失败的回调中直接发起重试，与gRPC内部机制协同工作：

void Client::SubscribeNotifications() {
    auto stream = stub_->PrepareAsyncSubscribeNotifications(&context_, request_, nullptr);
    stream->StartCall([this, stream](grpc::Status status) {
        if (!status.ok()) {
            // 连接失败，延迟后重试（可根据需求调整间隔）
            std::thread([this]() {
                std::this_thread::sleep_for(500ms);
                SubscribeNotifications();
            }).detach();
            subscribed_.store(false);
            return;
        }
        // 订阅成功，标记状态并处理后续消息
        subscribed_.store(true);
        stream->Read(&response_, [this, stream](bool ok) {
            if (ok) {
                HandleNotification(response_);
                // 继续监听下一条消息
                stream->Read(&response_, std::move(handle));
            } else {
                // 流中断，重置状态并重试
                subscribed_.store(false);
                SubscribeNotifications();
            }
        });
    });
}

2. 调整gRPC退避参数 #

通过通道参数修改gRPC的默认退避策略，缩短最大退避时间，让客户端在后端启动后更快恢复连接：

grpc::ChannelArguments args;
// 设置初始退避时间100ms，最大退避时间500ms
args.SetInt(GRPC_ARG_MIN_RECONNECT_BACKOFF_MS, 100);
args.SetInt(GRPC_ARG_MAX_RECONNECT_BACKOFF_MS, 500);
auto channel = grpc::CreateCustomChannel(server_addr, grpc::InsecureChannelCredentials(), args);
auto stub = NotificationService::NewStub(channel);

3. 移除外部重试循环 #

删除外部的while循环和TryToSubscribeNotifications中的线程创建逻辑，避免冗余连接尝试触发gRPC退避机制，完全由客户端内部回调处理重试逻辑。

内容的提问来源于stack exchange，提问作者Ilya Lukin