小议 MySQL 的写前日志与 Redis 的写后日志

欢迎关注公众号：【冬瓜白】

相关文章：

• 《分布式事务之基于消息（一）最大努力通知》

前段时间，组内大佬发了一篇博客，他从实际业务场景出发，联想到 MySQL 的 WAL 技术。看了之后我又想到了 Redis 的 AOF 写后日志机制。借此机会，我也重新学习了这两个技术，并从它们的设计思路中表达一些个人观点。

什么是写前日志（WAL）？

写前日志（Write-Ahead Logging, WAL） 是一种先记录日志再更新数据的机制。它的核心思想是：在对数据进行修改之前，先将修改操作记录到日志中，以便在系统崩溃时通过日志恢复数据。

MySQL 中的 WAL 实现

在 MySQL 的 InnoDB 存储引擎中，WAL 的典型实现是 redo log（重做日志）。当有一条记录需要更新时，InnoDB 会先将更新操作写入 redo log，并更新内存中的数据页，而不是直接将数据写入磁盘。随后，后台线程会在适当的时候将内存中的数据页刷新到磁盘。

这种机制的优点是：

1. 提升写入性能：日志的写入是顺序 IO，速度远快于随机 IO。
2. 保障数据一致性：即使系统崩溃，redo log 也能帮助恢复未完成的事务，确保数据不丢失。

WAL 的工作流程

以下是 WAL 的典型工作流程：

1. 事务开始：记录事务的起始信息。
2. 写日志：将修改操作写入 redo log。
3. 更新内存：修改内存中的数据页。
4. 事务提交：将事务提交信息写入日志。
5. 后台刷盘：在系统空闲时，将内存中的数据页刷新到磁盘。

这种设计的核心是：日志优先于数据写入磁盘，从而实现高效的事务管理和数据恢复。

什么是写后日志（AOF）？

写后日志（Write-Behind Logging, AOF） 是一种先更新数据再记录日志的机制。它的核心思想是：在对数据进行修改后，将操作记录到日志中，以便在系统崩溃时通过日志重放恢复数据。

Redis 中的 AOF 实现

Redis 提供了 AOF（Append-Only File）机制来实现写后日志。每当有写操作发生时，Redis 会先将数据写入内存，然后将该操作以追加的方式记录到 AOF 文件中。AOF 文件可以在 Redis 重启时通过重放日志恢复数据。

Redis 的 AOF 提供了三种刷盘策略：

1. always：每次写操作都立即同步到磁盘，最安全但性能较差。
2. everysec：每秒将日志同步到磁盘，性能与安全性平衡。
3. no：由操作系统决定何时将日志写入磁盘，性能最高但可能丢失数据。

AOF 的工作流程

以下是 AOF 的典型工作流程：

1. 写入内存：将数据写入内存。
2. 记录日志：将操作追加到 AOF 文件。
3. 刷盘：根据配置的刷盘策略，将日志同步到磁盘。

这种设计的核心是：日志滞后于数据写入内存，以提升写入性能。

操作记录更新到磁盘的延迟是否会影响查询？

在 MySQL 的 InnoDB 引擎中，更新操作的流程是：先将操作记录写入 redo log，同时更新内存中的数据页（Buffer Pool），然后在系统空闲时将脏页（Dirty Page）异步刷入磁盘。这种设计可能会让人担心：如果数据尚未刷入磁盘，查询是否会受到影响？

答案是：不会影响查询，查询依然可以获取到最新的数据。

这是因为：

1. 内存优先：InnoDB 在查询时会优先从内存中的 Buffer Pool 读取数据。如果数据页已经被更新到内存（即变成脏页），查询会直接返回内存中的最新数据，而不会等待数据刷入磁盘。
2. 异步刷盘：将脏页刷入磁盘的操作是由后台线程异步完成的，主要是为了减少磁盘 IO 的频率，提高系统性能。这种延迟只影响磁盘上的数据一致性，但不会影响内存中数据的实时性。
3. 持久性保障：即使系统崩溃，未刷入磁盘的数据也可以通过 redo log 恢复，确保数据不会丢失。

因此，InnoDB 的设计既保证了查询的实时性，又通过异步刷盘优化了性能，同时利用 redo log 提供了数据的持久性保障。

WAL 与 AOF 的对比

技术设计的思考

在讨论 MySQL 的 WAL 技术和 Redis 的 AOF 机制时，我又想到了之前在《分布式事务之基于消息（一）最大努力通知》中表达的一个观点：技术设计的核心在于找到适合当前业务的解决方案，而不是拘泥于某种固定的形式。

就好比李小龙的截拳道哲学。截拳道的核心思想是：不拘泥于形式，以思想上的成熟觉悟为基础，找到最适合实际情况的解决方案。它强调“以水为本质”，灵活应对各种情况，将复杂化解于无形。截拳道的最大特点是注重“生活上的实际运用”，抛弃传统武术复杂的形式套路。

在技术设计中，这种哲学同样适用：

1. 了解现有的“招式”：在不拘泥于形式之前，我们需要先掌握现有的技术方案和设计模式。比如，理解 WAL 和 AOF 的优缺点，了解它们在不同场景中的适用性。
2. 灵活应对业务需求：没有一种技术是万能的“银弹”。我们需要根据业务场景的特点，选择最适合的解决方案，而不是盲目套用某种技术。
3. 注重实际运用：技术的最终目标是解决实际问题，而不是追求形式上的完美。比如，MySQL 的 WAL 技术通过异步刷盘提升性能，而 Redis 的 AOF 提供了多种刷盘策略，允许用户根据需求在性能和一致性之间做出权衡。

总结

MySQL 的写前日志（WAL）和 Redis 的写后日志（AOF）是两种经典的日志机制，它们分别在一致性和性能之间做出了不同的权衡。通过对比可以发现，日志机制的设计需要根据系统的应用场景、性能需求和数据一致性要求进行综合考虑。

正如截拳道所强调的那样，不要拘泥于形式，而是找到适合当前业务的解决方案。这种思维方式不仅适用于技术设计，也适用于我们解决生活中的各种问题。

没有银弹，但有智慧。