我目前面临的挑战是云计算在 IOPS 和 CPU 方面的局限性。我们的想法是长期将这些系统引入内部，但我认为可以采用更好的架构来更好地利用可用资源。
应用程序 A 每秒向文件系统写入 100-200+ 个文件。此文件系统曾经是远程挂载的文件系统，但现在正在本地写入，以获得尽可能高的 IOPS。我们目前以大约 200-300MB/s 的速度写入块存储。
应用程序 B 远程安装此文件系统并解析这些文件并将数据推送到 MySQL DB。执行此功能后，它会删除该文件。此应用程序非常耗费 CPU。我们正在使用更高效的多线程语言进行重写。
我们正在努力使解析器更加高效，但在此期间，我们需要找到一种方法来改进整个写入/读取过程。
如果我有超过 10 个解析服务器处理文件，那么应用程序 A 的服务器将需要等待大量 IO，导致服务器崩溃。如果我们有一个中央文件服务器，它也无法处理 IOPS，从而导致平均负载过高。
有没有比从文件系统写入/读取更好的选择？
我目前仅限于基于云的产品供应，并且将我们当前的解决方案扩展到我们需要的领域将花费我们每年超过 100 万美元。
答案1
这听起来像是 AWS Architect Pro 考试的问题。解决规模和价格问题似乎相当简单。有很多选择，这是我想到的第一个。
如果您说了您正在使用的云，您可能会得到更好的建议。大多数云都提供类似的功能，因此无论您使用哪个云，可能都没问题。无论您使用哪种云，您都可以使用 AWS S3 和 SQS，但您应该使用云原生的功能来降低成本。带宽可能很昂贵，延迟可能会产生影响。
- 让编写应用程序将文件存储在私有 S3 存储桶中。S3 将根据需要进行扩展。请谨慎命名文件 - 如果命名错误，您将会遇到瓶颈。读这个。
- 将一条消息放入 SQS 消息队列，其中包含 S3 上文件的位置以及任何其他命令
- 如果需要数据库，请设置 RDS 数据库。
- 拥有一组自动扩展的现货实例，它们从队列中读取并处理文件。让它根据队列大小进行扩展，这是一个内置指标。如果您的应用程序不是线程化的，并且您只能在每台服务器上运行一个实例，请使用多个小实例。
- 您可以拥有第二组自动扩展的按需实例，其扩展阈值高于现货实例组。这可能有点棘手/麻烦，我不是 100% 确定如何做到这一点。
使用现货实例和 S3 而不是按需实例和文件系统，我预计你的账单会下降显著地。使用 SQS 和 S3 需要一点开发工作，但也不是很多，API 很好，而且有很多示例。
答案2
与其写入许多文件，不如将这些数据块发送到一个进程（或一个集群），然后将其按顺序写入某种存档文件。也许这样tar比较合适。即使在 HDD 上，以 300MB/秒的速度写入单个文件也不算太重。
另外，考虑使用远程文件挂载以外的其他方法。大量网络文件系统的读写用户表明存在锁定问题，尤其是在目录节点上。可能最好在源计算机上使用一些作业运行程序来拾取文件并将其发送到某种服务器进程。例如，HTTP PUT 直接发送到写入数据库的进程。
查看作业队列产品。例如 RabbitMQ。听起来你可能正在做一些适合这种架构的事情。