典型的ACID RDBMS会在每次提交时同步到磁盘吗？

Question

ACID中的“D”意味着“持久性”，维基百科将其定义为：“每个提交的事务都受到保护，以防断电/崩溃/错误，并且不会被系统丢失，因此可以保证完成”。

但是，这意味着每个事务都必须同步到磁盘，然后才能报告为成功，而不只是刷新。(‘flush’=发送到操作系统级，‘sync’=发送到物理磁盘盘片)。这将使实现高事务率的RDBMS变得不可能。

流行的RDBMS真的同步每个事务吗？

Answer 1

使用磁盘进行持久化的数据库确实必须写入磁盘才能使事务持久。此外，它们还必须同步到磁盘，以避免回写式缓存造成的任何损失。

为了实现高性能，数据库将使用组提交，从而一个提交周期中的多个事务将使用相同的写/同步操作来使所有事务持久。在它们都附加到同一事务日志的情况下，这是可能的。

这可能意味着单个提交的响应可能会延迟(同时等待其他人加入提交周期)，但整个数据库的总体吞吐量要大得多，因为写入/同步的成本在多个事务之间分摊。例如，每个单独的事务可能需要10毫秒，但数千个事务都能够在同一周期内提交。

数据库通常会测量有多少事务是活动的，以判断是否值得让任何单个事务等待其他事务加入提交周期，以便在负载非常轻的系统上，事务不需要等待其他事务。

并非所有数据库都使用磁盘来保证持久性。例如，VoltDB依赖于跨多个服务器的内存中保存的事务副本。如果其中一台服务器死了，事务仍然可以在其他地方使用。因此，事务只需要确保事务已传输到足够数量的服务器，以确保持久性。

这也提出了什么是持久的问题？单个磁盘是否耐用？如果磁盘出现故障，则不会。RAID阵列是否耐用？如果有灾难性的突袭腐败，就不会。持久性的唯一保证是跨多个远程数据库实例复制事务-但并不是每个人都需要这种级别的保证。不应将耐久性视为二元选项，而应将其视为耐久性级别的选择。

Answer 2

'disk‘不仅仅是一个文件。commit将写入transaction log，然后将其用于更新数据库。如果系统在更新之前崩溃，则可以从日志中重建事务。

Answer 3

是的，它被称为回滚日志。

你为什么认为这是不可能的？

如果你说同步每个事务都没有发生，你有什么建议来解决这个问题？