在文本文件中缓存数据——更好的选择

Question

我目前正在开发一个应用程序，该应用程序将数据读取和写入到应用程序内的读/写目录中的文本文件作为缓存策略。

我的直觉是，这太不对了。

我认为这些值应该存储在 ASP.NET 缓存或其他专用内存缓存中，例如 Redis 或类似的东西。

您能否提供任何数据来支持我的信念，即在网络服务器上写入和读取文本文件作为一种缓存形式是错误的做法？或者提供任何数据来证明我的错误并表明这是正确的做法？

您会提供哪些其他选项来实现此缓存？

编辑：

在一个示例中，基于关键字执行复杂搜索。此搜索的结果是一个 Guid 列表。然后将其转换为连接的、以逗号分隔的字符串，通常少于 100,000 个字符。然后使用该关键字作为其名称将其写入文件，以便使用该关键字的其他请求不需要执行复杂的搜索。有一个到期日 - 我认为三天左右，但我认为它不需要（或应该）那么长

我通常会使用 ASP.NET 服务器缓存来存储这些数据。

Answer 1

我能想到四个原因：

1. Web 服务器可能有许多并发请求。虽然您可以编写管理文件锁定的逻辑（互斥体、易失性对象），但如果您计划将来能够重构它，那么实现它是一件痛苦的事情并且需要抽象（一个接口）——您会想要这样做，因为最终demand on the filesystem resource will be heavier 比在多线程上下文中可以解决的问题。

2. 说到这一点，除非您实现分页，否则您每次访问它时都会读取和写入整个文件。那很慢。与内存中的操作相比，即使分页也很慢。将what you think you can get out of the disks you're using 与Redis benchmarks from New Relic 进行比较。随意根据文件的估计大小和等待写入文件的线程数执行您自己的计算。你永远不会匹配内存中的缓存。

3. 此外，如前所述，异步文件系统操作have to be managed 同时等待同步 I/O 操作完成。同时，除非您让应用程序等待，否则您将无法获得与 Web 应用程序执行的操作一致的数据。我知道解决这个问题的唯一方法是写入和读取一个足够快的托管系统以跟上进来的请求，这样你的缓存状态几乎总是会反映最新的变化。

4. 最后，由于您讨论的是文本文件，而不是数据库，您将确定自己的键值对对象表示法，或者使用一些预制格式，例如 JSON 或 XML。无论哪种方式，只需要一个失败的操作或一个格式不正确的添加来使整个文本文件不可读。然后，您可以选择从备份中恢复（假设您实施了版本控制......）并丢失大量数据，或者丢弃数据并重新开始。如果数据对您来说并不重要，那么就没有理由使用磁盘。如果将事物保存在磁盘上的目的是为了后代保留它们，那么您应该使用数据库。如果拥有关系数据库不如速度重要，您可以使用 NoSQL 上下文，例如 MongoDB。

简而言之，通过使用文件系统和文本，您必须重新发明轮子的次数比任何不是完全受虐狂的人都喜欢。