Java 从多个线程获取输入，并将固定大小的文件上载到S3

我编写了一个线程安全类，从多个线程获取输入，并在S3运行到固定大小后将结果上传到S3

S3出口类

客户端调用export方法来传递数据，如果抛出异常，客户端将稍后传递该数据。 为了避免在重新启动应用程序时丢失数据，我在创建S3Exporter对象时添加了一个关机挂钩：

    S3Exporter exporter = new S3Exporter(10000);
    Runtime.getRuntime().addShutdownHook(new Thread(() -> exporter.end()));

我担心的是这个类是不可伸缩的，我的意思是当数据越来越多时，它可能成为系统的瓶颈。我可以想出两种方法来改善这种情况：

异步执行耗时的上载操作：使用执行器上载并调用关机挂钩中的ThreadPoolExecutor.waitTermination。 只需将数据放入导出方法中的LinkedBlockingQueue，并使用多个线程来处理它。根据我的理解，这种方式比第一种更具可扩展性 然后，我需要在shutdownhook线程中做更多的工作，以确保不会丢失接受的数据，据我所知，这不是一个好主意。我将承担在重新启动应用程序时丢失数据的风险，这是我最不想看到的

我的问题

我对可伸缩性的担心真的是个问题吗？为了让问题不那么愚蠢，假设数据大小为几个字节，调用导出方法的TPS为500 如果第一个问题的答案是肯定的，那么我的改进是什么，对吗？如何进行清理工作以避免丢失数据？

---

可伸缩性取决于需求、约束、期望的服务级别、个人偏好、预期的用户增长率，尤其是资金：给定无限的资源，每一个软件都可以伸缩。你没有提到任何，所以我猜你没有任何实际数字。在这个阶段，作为一名程序员，你的工作是制作一个正确的程序，使用可预测的资源量

你的计划似乎是正确的，你的大部分假设也是正确的。然而，我建议立即将块存储到一些本地持久性数据库或原始文件系统中，并定期在单独的线程中运行作业，将块组上载到S3，并删除任何可以使用Camel处理无聊部分的关闭挂钩。这是因为这样的钩子不可靠，只能用作快速和可选清理的最后一个资源（可选），也就是说，您必须做好准备，直到最后才能正确运行清理

使用文件而不是内存，您的数据可以经受致命错误的考验，并且应用程序所需的工作内存几乎与负载无关：有大量无关的额外CPU和一些比内存便宜得多的磁盘I/O

    S3Exporter exporter = new S3Exporter(10000);
    Runtime.getRuntime().addShutdownHook(new Thread(() -> exporter.end()));