Redis AOF 和 Tarantool WAL 日志的区别
Difference between Redis AOF and Tarantool WAL log
我正在阅读这篇关于 Tarantool 的文章article，他们似乎说 AOF 和 WAL 日志的工作方式不同。
Tarantool: besides snapshots, it has a full-scale WAL (write ahead
log). So it can secure data persistency after each transaction
out-of-the-box. Redis: in fact, it has snapshots only. Technically,
you have AOF (append-only file, where all the operations are written),
but it requires manual control over it, including manual restore after
reboot. Simply put, with Redis you need to manually suspend the server
now and then, make snapshots and archive AOF.
有人可以更清楚地解释这两种策略之间的区别以及每种策略在高层次上的工作原理。
我一直认为 Redis AOF 与 SQL 数据库事务日志的工作方式相同，例如在 Postgresql 中实现的，但我可能错了。
AOF 是 Redis 的主要持久化选项。只要有修改内存中数据集的写操作，该操作就会被记录下来。因此在重启期间，Redis 将重放所有操作以重建数据集。您还有 3 种不同的 fsync 配置策略可供选择（no、everysec、always）。 FWIW，如果您想要良好的数据安全级别，通常建议同时使用 AOF + RDB。这有点超出您的问题范围，但我想我会提到它。
Tarantool 使用了一种叫做 "WAL writer" 的东西。这将 运行 在一个单独的线程中并记录操作数据的请求 "insert and update requests"。重新启动时，Tarantool 通过读取 WAL 文件并重放每个请求来恢复。
内部结构明显不同，但在较高层次上它们非常相似。文章中的持久性比较很奇怪，根本不正确。
有关低级别差异的更多信息，请参阅上面列出的文档。
希望对您有所帮助
Redis:
- IIRC，Redis 在处理请求的同一个线程中写入日志。如果磁盘由于某种原因（RDB 写入、AOF 重写）变慢，则会导致停顿：单次写入操作可能会冻结整个服务线程，直到
write 系统调用完成。
- Redis 无法使用AOF 进行复制恢复，因为AOF 不包含操作位置。如果缓冲区不够大以容纳自上一个快照启动以来的操作，则副本只能依赖主服务器的内存缓冲区并重新请求完整快照。我在半小时内有一次未恢复的副本，直到我认出它并手动增加 master 的缓冲区大小。
塔兰图尔：
- Tarantool 在单独的线程中写入 WAL，事务线程异步地与之对话。可能有很多写操作同时等待 WAL，而读操作根本不会被阻塞。
- Tarantool 将 LSN 存储在 WAL 中，副本可以使用 WAL 进行恢复，即使它已关闭数小时。副本甚至没有“重新请求快照”操作，因为在实践中它永远不会滞后到主服务器上没有足够的 WAL。
我正在阅读这篇关于 Tarantool 的文章article，他们似乎说 AOF 和 WAL 日志的工作方式不同。
Tarantool: besides snapshots, it has a full-scale WAL (write ahead log). So it can secure data persistency after each transaction out-of-the-box. Redis: in fact, it has snapshots only. Technically, you have AOF (append-only file, where all the operations are written), but it requires manual control over it, including manual restore after reboot. Simply put, with Redis you need to manually suspend the server now and then, make snapshots and archive AOF.
有人可以更清楚地解释这两种策略之间的区别以及每种策略在高层次上的工作原理。
我一直认为 Redis AOF 与 SQL 数据库事务日志的工作方式相同，例如在 Postgresql 中实现的，但我可能错了。
AOF 是 Redis 的主要持久化选项。只要有修改内存中数据集的写操作，该操作就会被记录下来。因此在重启期间，Redis 将重放所有操作以重建数据集。您还有 3 种不同的 fsync 配置策略可供选择（no、everysec、always）。 FWIW，如果您想要良好的数据安全级别，通常建议同时使用 AOF + RDB。这有点超出您的问题范围，但我想我会提到它。
Tarantool 使用了一种叫做 "WAL writer" 的东西。这将 运行 在一个单独的线程中并记录操作数据的请求 "insert and update requests"。重新启动时，Tarantool 通过读取 WAL 文件并重放每个请求来恢复。
内部结构明显不同，但在较高层次上它们非常相似。文章中的持久性比较很奇怪，根本不正确。
有关低级别差异的更多信息，请参阅上面列出的文档。
希望对您有所帮助
Redis:
- IIRC，Redis 在处理请求的同一个线程中写入日志。如果磁盘由于某种原因（RDB 写入、AOF 重写）变慢，则会导致停顿：单次写入操作可能会冻结整个服务线程，直到
write系统调用完成。 - Redis 无法使用AOF 进行复制恢复，因为AOF 不包含操作位置。如果缓冲区不够大以容纳自上一个快照启动以来的操作，则副本只能依赖主服务器的内存缓冲区并重新请求完整快照。我在半小时内有一次未恢复的副本，直到我认出它并手动增加 master 的缓冲区大小。
塔兰图尔：
- Tarantool 在单独的线程中写入 WAL，事务线程异步地与之对话。可能有很多写操作同时等待 WAL，而读操作根本不会被阻塞。
- Tarantool 将 LSN 存储在 WAL 中，副本可以使用 WAL 进行恢复，即使它已关闭数小时。副本甚至没有“重新请求快照”操作，因为在实践中它永远不会滞后到主服务器上没有足够的 WAL。