Redis AOF与Tarantool测井的差异

Question

我读到了关于Tarantool的文章，他们似乎说AOF和WAL的工作方式不同。

Tarantool:除了快照，它还有一个完整的WAL (先写日志).因此，它可以在每次事务开箱后确保数据的持久性。事实上，它只有快照。从技术上讲，您有AOF (仅添加文件，所有操作都在这里编写)，但它需要手动控制，包括重新启动后的手动恢复。简单地说，使用Redis，您需要不时手动挂起服务器，创建快照并存档AOF。

有谁能更清楚地解释两种策略的不同之处，以及每一种策略在高层次上的工作方式。

我一直认为Redis对SQL数据库事务日志的工作方式与Postgresql实现的相同，但我可能错了。

Answer 1

AOF是Redis的主要持久性选项。每当有一个写操作修改内存中的数据集时，该操作就会被记录下来。因此，在重新启动期间，Redis将重播所有的操作来重建数据集。您还可以选择3种不同的fsync配置策略(不，每个秒，总是这样)。FWIW，通常建议在需要良好的数据安全级别时，同时使用AOF + RDB。这有点超出了你问题的范围，但我想我应该提一下。

主Redis持久化文档

红系持久性神秘主义

Tarantool使用的是一个叫做"WAL作家“的东西。这将在单独的线程和日志请求中运行，这些请求操作数据“插入和更新请求”。在重新启动时，Tarantool通过读取WAL文件并重播每个请求来恢复。

Tarantool持久化文档

很明显，他们的内部结构是不同的，但是在很高的水平上，他们是非常相似的。本文中的持久性比较非常奇怪，而且根本不正确。

有关低级别差异的更多信息，请参阅上面列出的文档。

希望这有帮助

Answer 2

红色信息系统：

• IIRC，Redis在服务请求的同一个线程中写入日志。如果磁盘由于某种原因(RDB写，AOF重写)而慢，这会导致停止:单个写操作可能会冻结整个服务线程，直到write syscall完成。
• 由于AOF不包含操作位置，所以Redis无法使用AOF进行复制还原。副本只能依赖主内存缓冲区和重新请求完整快照，如果缓冲区不够大，无法容纳自上一次快照启动以来的操作。在半小时内，我曾经有过一次没有恢复的副本，直到我认出它，并手动增加了主缓冲区的大小。

Tarantool：

• Tarantool在一个单独的线程中编写WAL，事务线程与它异步对话。可能同时有许多写操作在等待WAL，而且读取操作完全没有被阻塞。
• Tarantool将LSN存储在WAL中，而副本可以使用WAL进行修复，即使它被关闭了几个小时。副本甚至没有操作“重新请求快照”，因为在实践中，它从来没有滞后到没有足够的WAL在主。