简单文件的事务实现

Question

我是编写嵌入式系统应用程序团队的一员。该应用程序经常遭受由电力短缺引起的数据损坏。我认为实施某种交易会阻止这种情况发生。一种情况包括在写入一些额外存储（事务日志）之前复制文件区域。还有什么其他可能性？

Answer 1

数据库使用各种技术来确保状态得到适当保留。

1. DBMS通常会保留一个复制的控制文​​件 - 多个设备上的多个同步副本。两个就够了。更多，如果你是偏执狂。控制文件提供了一些用于定位其他文件及其预期状态的关键参数。控制文件可以包含“数据库版本号”。

2. 每个文件都有多种形式的“版本号”。很多时候它是以简单的形式加上一些XOR补码，这样两个版本号可以通过简单的方式检查以获得正确的关系，并匹配控制文件的版本号。

3. 所有交易都写入交易日记帐。然后将事务日志写入数据库文件。

4. 在写入数据库文件之前，原始数据块将复制到“之前的图像日记”或回滚段或其他类似文件。

5. 当块被写入文件时，序列号会更新，并且该块将从事务日志中删除。

您可以阅读RDBMS技术的可靠性。

Answer 2

有很多方法可以做到这一点;通常，所需的唯一假设是小写（＆lt; 4k）是原子的。例如，以下是CouchDB的用法：

• 除其他外，4k标头包含包含所有数据的BTree根目录的文件偏移量。
• 该文件仅附加。需要更新时，将更新写入文件末尾，然后是任何已修改的BTree节点，包括根目录。然后，刷新数据，并将根节点的新地址写入标题。

如果程序在写入更新时但在写入标题之前死亡，则会丢弃文件末尾的额外数据。如果在写入标题后失败，则写入完成并且一切正常。由于该文件仅附加，因此这些是唯一的故障情形。这还有一个优点，即提供没有读锁定的多版本并发控制。

当文件增长太长时，只需读出所有“实时”数据并将其写入新文件，然后删除原始数据。

Answer 3

您可以通过在文件系统周围使用现有的事务管理器来避免自己实现此类事务日志，例如： XADisk

旧链接不再可用，github仓库为here。