Python 中的原子状态存储？

Question

我正在一个不可靠的系统上开展一个项目，我认为该系统随时可能失败。我想保证的是，如果我 write_state 并且机器在操作过程中失败，则 read_state 将读取有效状态或根本不读取任何状态。我已经实现了一些我认为会在下面起作用的东西——如果有人知道的话，我对对此的批评或替代解决方案很感兴趣。

我的想法：

import hashlib, cPickle, os

def write_state(logname, state):
    state_string = cPickle.dumps(state, cPickle.HIGHEST_PROTOCOL)
    state_string += hashlib.sha224(state_string).hexdigest()

    handle = open('%s.1' % logname, 'wb')
    handle.write(state_string)
    handle.close()

    handle = open('%s.2' % logname, 'wb')
    handle.write(state_string)
    handle.close()

def get_state(logname):
    def read_file(name):
        try:
            f = open(name,'rb')
            data = f.read()
            f.close()
            return data
        except IOError:
            return ''
    def parse(data):
        if len(data) < 56:
            return (None, '', False)
        hash = data[-56:]
        data = data[:-56]
        valid = hashlib.sha224(data).hexdigest() == hash
        try:
            parsed = cPickle.loads(data)
        except cPickle.UnpicklingError:
            parsed = None
        return (parsed, valid)

    data1,valid1 = parse(read_file('%s.1'%logname))
    data2,valid2 = parse(read_file('%s.2'%logname))

    if valid1 and valid2:
        return data1
    elif valid1 and not valid2:
        return data1
    elif valid2 and not valid1:
        return data2
    elif not valid1 and not valid2:
        raise Exception('Theoretically, this never happens...')

例如：

write_state('test_log', {'x': 5})
print get_state('test_log')

Answer 1

你的两份副本不起作用。文件系统可以重新排序，以便在将任何文件写入磁盘之前两个文件都被截断。

有一些文件系统操作保证是原子的：将一个文件重命名为另一个文件就是其中之一，只要该文件位于一个位置或另一个位置。然而，就 POSIX 而言，它不能保证在文件内容到达磁盘之前完成移动，这意味着它只为您提供锁定。

Linux 文件系统强制文件内容在原子移动之前到达磁盘（但不是同步），因此这可以满足您的要求。 ext4 在短时间内打破了这一假设，使得这些文件实际上更有可能变成空的。这被广泛认为是一个愚蠢的举动，此后已得到纠正。

无论如何，正确的方法是：在同一目录中创建临时文件（因此它位于同一文件系统上）；写入新数据； fsync 临时文件；在以前的版本上重命名它。这是操作系统可以保证的原子性。它还为您提供了耐用性，但代价是旋转磁盘，这就是应用程序开发人员不喜欢使用 fsync 并将有问题的 ext4 版本列入黑名单的原因。

Answer 2

我将添加一个异端回应：使用 sqlite 怎么样？或者，可能是 bsddb，但是这似乎已被弃用，您必须使用第三方模块。

Answer 3

我对数据库工作方式的模糊记忆是这样的。它涉及三个文件。控制文件、目标数据库文件和待处理事务日志。

控制文件具有全局事务计数器和散列或其他校验和。这是一个小文件，大小为一个物理块。一次操作系统级写入。

在目标文件中有一个包含真实数据的全局事务计数器，以及哈希值或其他校验和。

有一个待处理的事务日志，它只会增长，或者是一个有限大小的循环队列，或者可能会滚动。没关系。

1. 将所有挂起的事务记录到简单日志中。有一个序列号和更改的内容。

2. 更新事务计数器，更新控制文件中的哈希值。一写，脸就红了。如果失败，那么什么都没有改变。如果成功，则控制文件和目标文件不匹配，表明事务已启动但尚未完成。

3. 对目标文件进行预期的更新。查找开头并更新计数器和校验和。如果失败，则控制文件的计数器比目标文件多 1。目标文件已损坏。当此操作有效时，最后记录的事务、控制文件和目标文件都在序列号上达成一致。

您可以通过重播日志来恢复，因为您知道最后一个有效的序列号。

Answer 4

在类似 UNIX 的系统下，通常的答案是进行链接舞蹈。使用唯一名称创建文件（使用 tmpfile 模块），然后在将内容同步到所需（发布）状态后，使用 os.link() 函数创建到目标名称的硬链接。

在此方案下，您的读者在状态正常之前不会看到该文件。链接操作是原子的。成功链接到“就绪”名称后，您可以取消临时名称的链接。如果您需要保证旧版本 NFS 的语义而不依赖于锁定守护进程，则需要处理一些额外的问题。

Answer 5

我认为你可以简化一些事情

def read_file(name):
    try:
        with open(name,'rb') as f
            return f.read()
    except IOError:
        return ''

---

if valid1:
    return data1
elif valid2:
    return data2
else:
    raise Exception('Theoretically, this never happens...')

你可能不需要一直写入这两个文件，只需写入 file2 并将其重命名为 file1 即可。

我认为硬重置（例如断电）仍然有可能导致两个文件由于延迟写入而无法正确写入磁盘