algorithm - 存储用于流式传输的仅附加系列文件的最佳实践方法是什么？

Question

我想做的事情:

• 文件到达。假设一个文件是一个二进制 blob，它的文件名是合法的。文件通常很小。

• 当文件到达时，它会被分配一个 ID。该文件存储在磁盘上，由 ID 键控。

• 吞吐量和存储将在单个服务器和硬盘的能力范围内，但对于简单的实现来说太大太快了。存储是仅追加的，写入的文件永远不会更改，但系统可能会删除旧文件以回收存储。

• 检索这些文件的访问模式是“此 ID 之后的所有内容:...”，并且由按到达顺序排列的流式文件组成。如果给定一个空白 ID，将流式传输所有已知文件。

• 如果文件是在请求之后添加的，它们也会被流式传输。到达最新文件后，客户端可以保持连接打开并等待新文件。

• 对于流式传输的每个文件，客户端都会被告知其 ID。客户的工作是跟踪它最后看到的 ID。该 ID 可用于在断开连接后恢复。

• 它需要处理流中不同 ID 位置的多个并发客户端读取。

我的问题:

1. 我应该自己实现吗？如果是这样，最佳做法是什么？依赖文件系统和目录不好，使用聚合文件和偏移索引会更好吗？我很确定尝试将数据放入 SQL 数据库中是不好的，它们不是为这种流式阅读器设计的。

2. 或者是否有一个现有工具(NoSQL DB、消息队列等)可以满足我上面的要求？它是否可靠且不占用资源？

Answer 1

在某种程度上，这让我想起了 FTP ;-)

聚合文件几乎肯定会遇到(不允许)在写入进行时允许多次读取的困难。

单个文件应该没问题 - 我不知道在 (Linux) 文件系统中没有任何东西不应该让你以有效的方式实现它。当然，必须采取一些措施才能达到所需的安全级别(RAID 或...？)

在 ID 消息和文件数据消息之间交替需要一种能够处理某些突发事件、信号“数据结束”等的协议(protocol)。或者:“删除旧文件”是否不可能与“所有已知文件”发生冲突要求？