Memory 在内存中存储数据：会话vs缓存vs静态

一点背景知识：我正在开发一个web应用程序，在将数据交给用户编辑/操作之前，需要花费相当多的时间来准备/处理数据。数据请求任务需要15/20秒才能完成，需要几秒才能处理。一旦到了那里，用户就可以动态操作vaules。对值的任何操作都需要完全重新处理数据

更新：为了避免混淆，我只进行了一次数据调用（15秒的命中），然后希望将结果保存在内存中，这样在用户100%完成操作之前，我就不必再次调用它。因此，第一次拉动需要一段时间，但是，使用Ajax，我将点击内存中的数据以不断更新，并将响应时间保持在2秒左右（我希望如此）

为了提高效率，我将初始数据移动到内存中，并使用Ajax调用返回服务器，以便减少处理与此用户的更新相关的重新计算的处理时间

这里是我的问题，考虑到性能，假设在任何给定时刻只有一个用户使用此数据，那么存储此数据的最佳方式是什么

此外，用户可能会在此过程中工作几个小时。当用户使用数据工作时，如果他们的会话以某种方式中断，我需要某种故障保护来保存用户的当前数据（在db或序列化二进制文件中）。换句话说，我需要一个具有适当钩子的解决方案，以允许我在用户断开连接/分心太久的情况下转储内存对象的数据

到目前为止，我的想法如下：

会话状态-优点：锁定一个用户。具有满足故障保护要求的会话结束事件。缺点：在我目前的选择中表现最慢。会话结束事件有时很难确保正确触发

缓存-优点：性能良好。可以访问依赖项，这在以后可能是一个额外的好处，但在当前范围内并不真正有用。缺点：除了基于时间间隔的写入之外，没有简单的故障保护步骤。全局范围-必须确保用户之间的工作不会发生冲突

静态-优点：最佳性能。易于维护，因为我可以直接利用当前的类结构。缺点：除了基于时间间隔的写入之外，没有简单的故障保护步骤。全局范围-必须确保用户之间的工作不会发生冲突

有人对我应该选择的选项有什么建议/意见吗

谢谢

---

更新：忘了提到，我正在使用VB.Net、Asp.Net和SQLServer2005来执行此任务

使用会话，但不要依赖它

简单地说，让用户“命名”数据集，并主动为用户持久化它，可以是自动的，也可以是通过简单的“保存”按钮

您不能仅仅因为会话（通常）绑定到用户浏览器实例而依赖它。如果他们不小心关闭了浏览器（单击X按钮，他们的电脑崩溃等），那么他们将丢失所有的工作。那会很糟糕

---

一旦用户能够控制数据的“持久”状态，您就可以依靠会话将其保存在内存中，并将其用作缓存。

我想您已经用正反两方面回答了您的问题。但如果你想得到同行的认可，我会投票支持这次会议。尽管性能比较慢（您知道慢了多少吗？），但不管怎样，您的处理都将花费很长时间。你认为用户会知道15秒和17秒之间的区别吗？两者在网络上都是“永远”的，所以选择一个似乎最容易实现的

也许有点离题了。我建议将这些长处理调用放在异步（不要与AJAX的异步）页面中

看一看这篇文章，如果没有意义，请给我回复

---

我将投票支持秘密选项4：使用数据库。如果您谈论的是20秒以上的数据周转时间，那么考虑到您提供的选项的局限性，在内存中尝试这样做不会带来任何好处。您也可以在数据库中设置它（给它一个自己的表，或者如果需求很大，甚至是一个单独的数据库）。

我建议在向用户发送初始结果时，在一个新的数据库表中创建一个数据副本（我们称之为“编辑”）。如果性能有问题，请在后台线程中执行此操作

当用户编辑数据时，更新表（如果性能出现问题，也在后台线程中）。如果必须使用线程，则必须确保在开始更新行之前完成第一个线程

---

这允许用户在对结果感到满意时走开、回来，甚至重新启动浏览器并提交。

我会选择缓存方法，用于跨任何页面加载存储数据。您可以命名要在其中存储数据的缓存，以避免冲突

为了跟踪用户所做的更改，我采用了一种更老派的方法：每次用户进行更改时都附加到文本文件中，然后每隔一段时间扫描该文件以将更改保存回数据库。如果根据用户/帐户或其他会话唯一指示符命名文件，则不会出现冲突问题，应用程序（或其他支持应用程序，一般来说可能更好）可以扫描所有此类文件并更新数据库，即使会话已结束

第一部分可以调整为更交错地写入：将更改保存到会话，然后每隔一段时间将更改写入文件，然后每隔一段时间扫描文件。您可以根据性能对其进行调整，并选择可能的用户更改损失级别