我目前正在开发一个应用程序，用于缓存策略，读取和写入应用程序内读/写目录中的文本文件。
我的直觉反应是，这太糟糕了。
我认为这些值应该存储在ASP.NET Cache或其他专用的内存缓存中，例如Redis或类似的东西。
您是否可以提供任何数据来支持我的信念，即在网络服务器上写入和读取文本文件作为缓存形式是错误的做法？或者提供任何数据来证明我的错误，并证明这是正确的做法？
您将提供哪些其他选项来实现此缓存？
编辑：
在一个示例中，基于关键字执行复杂搜索。此搜索的结果是Guids列表。然后将其转换为以逗号分隔的连续字符串，通常少于100,000个字符。然后使用该关键字作为其名称将其写入文件，以便使用此关键字的其他请求不需要执行复杂搜索。有一个到期 - 我想三天或者其他什么，但我认为它不需要（或应该）那么久
我通常会使用ASP.NET Server Cache来存储这些数据。
答案 0 :(得分：3)
我可以想到四个原因：
Web服务器可能有很多并发请求。虽然你可以编写管理文件锁定的逻辑（互斥，易失性对象），但如果你计划将来能够重构它，那么实现这是一个痛苦并需要抽象（一个接口） - 你会想要这样做，因为最终demand on the filesystem resource will be heavier比在多线程环境中可以解决的问题更多。
说到这一点，除非你实现分页，否则每次访问它时都会读写整个文件。那很慢。与内存操作相比，偶数分页也很慢。将what you think you can get out of the disks you're using与Redis benchmarks from New Relic进行比较。您可以根据文件的估计大小和等待写入的线程数执行自己的计算。您永远不会匹配内存缓存。
此外，如前所述，异步文件系统操作have to be managed在等待同步I / O操作完成时。同时，除非您使应用程序等待，否则您将无法获得与Web应用程序执行的操作一致的数据。我知道修复该问题的唯一方法是写入和读取受管系统，该系统速度足以跟上进入的请求，因此缓存的状态几乎总是反映最新的更改
最后，由于您所讨论的是文本文件而不是数据库，因此您要么确定自己的键值对的对象表示法，要么使用某些预制格式（如JSON或XML）。无论哪种方式，它只需要一个失败的操作或一个格式不正确的添加来呈现整个文本文件不可读。然后你可以选择从备份恢复（假设你实现版本控制......）并丢失大量数据，或丢弃数据并重新开始。如果数据对您来说并不重要，那么就没有理由使用该磁盘。如果将内容保存在磁盘上的目的是为了后代保留它们，那么您应该使用数据库。如果拥有关系数据库不如速度重要，则可以使用NoSQL上下文，例如MongoDB。
简而言之，通过使用文件系统和文本，你必须重新发明轮子的次数比没有完全受虐狂的任何人都重要。