Memory 如何使用过程内存恢复更改？

是否有可能通过使用逻辑路径的某种方式来存储一组的所有更改（当更改发生时），这样就可以通过实质上的“后退”来恢复更改？我假设在变化发生时需要一些东西来映射这些变化，因此恢复这些变化的过程最终将是线性的

---

对于任何语无伦次表示歉意，这不适用于任何特定语言。相反，这是一个内存问题，也就是说，一个有限大小的集合*（例如，它可能是用户输入的某个存储）*可以连续改变*（例如，在任何给定的时间内，在任何时间内，它可以改变的程度没有限制）*按程序进行映射，以使新的-未来的-更改假定为先前更改的结果*（在第二个镜像存储中，可用于将集合的状态一直还原到其初始状态）*.

您可能需要查看一些功能数据结构。像Erlang这样的函数式语言可以很容易地回滚到早期状态，因为更改总是在新的数据结构上进行，而不是对现有的数据结构进行修改。虽然此功能可以在内部重复使用，但Erlang编程通常在“进程”的顶层大量使用此功能，因此在任何类型的失败时，它都会通过抛出异常来中止处理以及全部更改（在非函数式语言中，使用可变数据结构，您可以抛出异常以中止，但恢复原始数据将是您的程序的工作，而不是运行时的工作）。这是Erlang享有良好声誉的原因之一

这种函数式编程风格中的一些非常适用于非函数式语言，特别是不可变数据结构的使用，如不可变集、列表或树

例如，关于不可变集，我们可以设计一个面向功能的数据结构，在这种结构中，修改总是在给定一些更改和现有集（由添加和删除组成的更改集）的情况下生成一个新的集。您可以将旧的集挂起以供参考（由任何人）；具有自动垃圾回收功能的语言在旧语言不再使用（引用）时回收旧语言

您可以在设置的数据结构中放置一个id或标记，这样您可以进行一些自省，以查看某人拥有的数据结构id。您还可以捕获每个新版本生成的基础id；这将为您提供一些历史或沿袭

如果需要，您还可以在新数据结构中捕获对整个旧数据结构的引用，或者，您可以在生成所有数据集时维护这些数据集的全局列表。但是，如果这样做，您将不得不承担更多的存储管理责任，因为自动收集器可能不会找到任何未使用（未引用）的数据集无需额外帮助即可收集垃圾

数据库设计在其事务控制器中完成了一些这方面的工作。就您的问题而言，您可以将数据库视为一个美化的集合。您可以研究MVCC（多版本并发控制）作为一个在文献中写得相当好的例子，这种技术保留了数据结构的旧快照版本（暂时），这意味着突变总是出现在数据的新版本中。旧快照将被保留，直到没有活动事务引用它；然后被丢弃。当两个同时运行的事务都修改数据库时，它们都会基于相同的当前和最新数据集获得新版本。（事务控制器确切地知道每个事务基于哪个版本，尽管事务的客户端看不到版本信息。）假设两个并发事务都选择提交其更改，则事务控制器中的版本控制会识别第二个提交者正在尝试提交的更改集不是第一个的逻辑继承者（因为我们上面假设的两个更改集都基于相同的早期版本）。如果可能，事务控制器将合并更改，就好像第二个提交人确实在处理第一个提交人提交的另一个较新版本一样。（对于何时可能，有不同的定义，MVCC说是在没有写入冲突的情况下，这不是一个完美的答案，但快速且可扩展。）但如果不可能，它将中止第二提交人事务并通知第二提交人（如果他们愿意，他们有机会从较新的基础开始重试其事务）。在这种情况下，并发事务运行的各种快照版本可能会共享大部分数据（首先查阅一些特定于事务的更改集）以降低快照的成本。通常没有提供用于访问旧版本的API，因此在此域中，事务控制器知道，当事务失效时，它们使用的原始快照版本也可以（引用计数和）失效

另一个方面是使用仅附加文件。日志记录是记录更改的一种方式；有些数据库100%基于面向日志的设计

BerkeleyDB有一个很好的日志结构。虽然它主要用于恢复，但它确实包含所有历史记录，因此您可以从日志中重新创建数据库（直到您清除日志为止，在这种情况下，您还应该归档数据库）。此外，还需要有人决定何时可以启动新日志文件，何时可以清除旧日志文件，这样可以节省空间

这些数据库技术也可以应用于内存中（当然，没有什么是免费的）

无论如何，是的，在某些字段中可以执行此操作

不变的数据结构有助于保存历史，只需保留旧副本；更改总是转到新副本