适用于大量小型转移的Netty应用程序设计

Question

我正在尝试决定如何使用我认为不寻常的要求设计Netty应用程序。基本上有一个客户端发起请求。该请求转换为英语为“Go递归地在目录/任何/下获取一堆小小的文件，我可以告诉你关于这些文件的所有信息是他们的名字在AAAAAAA.bin和CCCCCCC.bin之间”。

因此，服务器需要接受请求，并开始扫描服务器端的某些目录，然后开始快速流式传输所有这些小文件。性能至关重要，但确保我收到AAAAAAA.bin和CCCCCCC.bin之间的所有文件也是如此。

因此，使客户端和服务器基本上不同步是一个好的设计吗？换句话说，客户端启动对话，发送请求，并简单地接收确认UUID令牌或其他东西，然后服务器开始收集文件（可能每个线程一个），联系客户端，并将其交给单个文件与UUID？我认为客户端可以定期询问服务器“你是否完成了我的请求与UUID令牌/ sometoken /？匹配？

我不太确定如何配置，因为客户端和服务器都将启动对话。或者，也许其他人有更好的设计理念？同样，性能（从请求启动到完成所有文件传输的总时间）至关重要。

谢谢！

Answer 1

假设你完全控制了协议（即你不仅限于HTTP），那么可能就像

1. 客户端连接到服务器并发送目录请求。如果客户端正在重新启动中止传输，则使用来自2
的令牌发送请求
2. 服务器使用唯一令牌进行此传输。如果正在重新启动传输，它将使用来自1的令牌进行响应。
3. 服务器识别此传输的所有文件，为每个文件提供唯一的ID，并将文件集与来自2的令牌相关联（可能希望在生成令牌之前找出文件）
4. 对于每个文件，服务器发送一条消息，包括文件长度，唯一文件ID，文件（以及任何其他信息，如文件名）。服务器尽快发送每个文件，不等待来自5的确认。
5. 客户端使用唯一文件ID确认收到的每个文件。
6. 发送完最后一个文件后，服​​务器会发送“传输完成”消息。

以上所有通信都是通过一个通道进行的。重要的一点是，您要异步传输文件和接收确认，从而减少网络延迟。

如果你有很多文件，我不会在每个文件中使用一个帖子。可能是将要发送的每个文件添加到作业队列的线程池，或者每个唯一目录可能会添加到作业队列中，并且线程一次处理一个目录。您可能需要将调用同步到channel.write（..）。我也假设客户端可以不按顺序接收文件。

实际上，我最初只用一个线程来读取文件。一旦它可靠地工作，看看是否有多个线程使您能够通过保持网络繁忙（即不等待读取下一个文件）来提高性能。

当写入通道时，我可能会写入包含文件详细信息的对象（唯一ID，文件数据，如果足够小，文件名，如果需要），然后有一个编解码器，可以将对象转换为通道缓冲区。

根据您的具体情况，客户端可以打开与服务器的多个连接，您可以为特定文件读取线程分配连接，从而避免任何通道同步问题。您可以通过这种方式获得一些性能提升，但最有可能的是，您只会看到连接之间共享的可用带宽。