如何用gRPC流下载超100MB大文件并在服务端跟踪分块？

先给你明确结论：在分块大小固定的情况下，完全可以不用显式传输分块编号。客户端可通过已接收的总字节数跟踪下载进度；若需断点续传，只需让客户端把已下载的字节偏移量传给服务端，服务端从对应位置开始发送文件即可。

另外要说明：你当前的DownloadFile RPC是客户端单次请求、服务端流式响应的单向模式，并非双向流。如果只是客户端被动下载完整文件、跟踪进度，现有模式下无需修改服务端；如果要支持断点续传，则需要调整RPC定义和服务端逻辑。

具体实现方案 #

1. 基础场景：全量下载+客户端进度跟踪 #

如果只是客户端下载完整文件，不需要断点续传，服务端保持现有逻辑即可。客户端只需维护一个计数器，每次收到Bytes分块后，将分块字节数累加，就能算出当前下载进度，甚至可以通过「总接收字节数 ÷ 固定分块大小」得到当前对应的分块序号。

客户端伪代码示例：

long receivedBytes = 0;
final int FIXED_CHUNK_SIZE = 1024 * 1024; // 固定1MB分块

fileServiceStub.downloadFile(reqFilePath, new StreamObserver<Bytes>() {
    @Override
    public void onNext(Bytes bytes) {
        receivedBytes += bytes.getValue().size();
        int currentChunkIndex = (int) (receivedBytes / FIXED_CHUNK_SIZE);
        // 将分块写入本地文件
        writeToLocalFile(bytes.getValue());
        // 可打印进度：receivedBytes / 文件总大小 * 100%
    }

    @Override
    public void onError(Throwable t) {
        // 处理下载错误，比如网络中断
    }

    @Override
    public void onCompleted() {
        // 下载完成逻辑
    }
});

2. 进阶场景：断点续传（无分块编号） #

如果需要支持断点续传（客户端断开后从上次中断位置继续下载），我们可以修改RPC定义，让客户端在请求时带上已接收的字节偏移量，服务端从该偏移量开始读取文件分块发送，全程无需传递分块编号。

修改后的Proto文件

message DownloadRequest {
  string file_path = 1;
  int64 offset = 2; // 客户端已接收的字节数，服务端从该位置开始发送
}

message BytesChunk {
  bytes data = 1;
  bool is_last = 2; // 标记是否为最后一个分块（可选，方便客户端判断结束）
}

service FileService {
  rpc DownloadFile(DownloadRequest) returns (stream BytesChunk) {}
}

服务端实现调整

@Override
public void downloadFile(DownloadRequest request, StreamObserver<BytesChunk> responseObserver) {
    File file = new File(request.getFilePath());
    if (!file.exists()) {
        responseObserver.onError(Status.NOT_FOUND.withDescription("文件不存在").asRuntimeException());
        return;
    }

    long fileSize = file.length();
    long offset = request.getOffset();

    // 校验偏移量合法性
    if (offset < 0 || offset > fileSize) {
        responseObserver.onError(Status.INVALID_ARGUMENT.withDescription("无效的偏移量").asRuntimeException());
        return;
    }

    // 如果已经下载完成，直接标记结束
    if (offset == fileSize) {
        responseObserver.onCompleted();
        return;
    }

    int FIXED_CHUNK_SIZE = 1024 * 1024; // 固定1MB分块
    try (RandomAccessFile raf = new RandomAccessFile(file, "r")) {
        raf.seek(offset);
        byte[] buffer = new byte[FIXED_CHUNK_SIZE];
        int readBytes;
        while ((readBytes = raf.read(buffer)) != -1) {
            BytesChunk chunk = BytesChunk.newBuilder()
                    .setData(ByteString.copyFrom(buffer, 0, readBytes))
                    .setIsLast(raf.getFilePointer() == fileSize)
                    .build();
            responseObserver.onNext(chunk);
        }
        responseObserver.onCompleted();
    } catch (IOException e) {
        responseObserver.onError(Status.INTERNAL.withDescription("文件读取失败：" + e.getMessage()).asRuntimeException());
    }
}

客户端断点续传逻辑

客户端本地记录已接收的字节数（比如存在本地文件或配置中），下次请求时将该数值作为offset传给服务端：

// 从本地读取已下载的字节数（比如从本地文件的长度获取）
long downloadedBytes = new File(localSavePath).length();

DownloadRequest request = DownloadRequest.newBuilder()
        .setFilePath("远程文件路径")
        .setOffset(downloadedBytes)
        .build();

fileServiceStub.downloadFile(request, new StreamObserver<BytesChunk>() {
    @Override
    public void onNext(BytesChunk chunk) {
        // 将分块追加写入本地文件
        appendToLocalFile(chunk.getData());
        downloadedBytes += chunk.getData().size();
    }

    @Override
    public void onError(Throwable t) {
        // 下载出错，下次启动时继续用downloadedBytes作为偏移量续传
    }

    @Override
    public void onCompleted() {
        // 下载完成，可清理本地进度记录
    }
});

关键注意点 #

• gRPC流的有序性：gRPC基于HTTP/2实现，默认保证流内消息的有序性，服务端按顺序发送的分块，客户端一定会按顺序接收，这是无需分块编号的核心前提。
• 分块大小固定的意义：固定分块大小只是方便客户端计算分块序号，对于进度跟踪和断点续传来说，真正核心的是字节偏移量，而非分块编号。
• 异常可靠性：客户端需要可靠保存已接收的字节数，避免传输中断后丢失进度，导致下次续传重复下载或漏下。

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