深入剖析`Redo Log`与`Undo Log`：如何在崩溃恢复时保证事务的ACID特性？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Redo Log与Undo Log：崩溃恢复中的ACID卫士

各位好，今天我们来深入探讨数据库系统中至关重要的两个日志机制：Redo Log 和 Undo Log。它们在保证事务的ACID特性，尤其是在系统崩溃恢复时，扮演着不可或缺的角色。

ACID特性回顾

在深入Redo Log和Undo Log之前，我们先快速回顾一下ACID的含义：

原子性 (Atomicity): 事务是不可分割的最小工作单元，要么全部成功，要么全部失败。
一致性 (Consistency): 事务执行前后，数据库从一个一致性状态转移到另一个一致性状态。
隔离性 (Isolation): 并发执行的事务之间应该相互隔离，避免互相干扰。
持久性 (Durability): 事务一旦提交，其修改的数据应该被永久保存，即使系统崩溃也不会丢失。

Redo Log 和 Undo Log 的主要职责是保证事务的原子性和持久性。

Undo Log：回滚的保障

Undo Log，顾名思义，用于撤销（Undo）事务所做的修改。它记录了事务在修改数据之前的值（old value）。当事务需要回滚时（例如，事务执行失败或被用户主动中止），Undo Log 可以用来将数据库恢复到事务开始之前的状态，从而保证原子性。

Undo Log的工作原理

记录修改前的状态: 在事务修改任何数据之前，数据库系统会将原始数据的值写入Undo Log。这个过程称为"Before Image"。
事务执行: 事务执行期间，对数据的修改会先写到内存缓冲区（Buffer Pool）中。
回滚: 如果事务需要回滚，系统会读取Undo Log中的Before Image，并将数据库中的数据恢复到原始值。

Undo Log示例

假设我们有一个简单的银行转账事务，从账户A向账户B转账100元。

账户A的余额：500元
账户B的余额：200元

下面是一个简化的Undo Log记录：

事务ID	操作	对象	修改前的值 (Before Image)
123	UPDATE	Account A	500
123	UPDATE	Account B	200

如果在事务执行过程中发生错误，需要回滚，系统会按照Undo Log的记录，将Account A的值恢复为500，Account B的值恢复为200，从而撤销转账操作。

Undo Log的存储方式

Undo Log通常以链表的形式存储，每个Undo Log记录指向前一个记录。这样方便事务回滚时，按照相反的顺序逐一撤销修改。

代码示例（伪代码）

class UndoLogEntry:
    def __init__(self, transaction_id, table_name, row_id, old_value):
        self.transaction_id = transaction_id
        self.table_name = table_name
        self.row_id = row_id
        self.old_value = old_value
        self.prev = None  # 指向前一个UndoLogEntry

class Transaction:
    def __init__(self, transaction_id):
        self.transaction_id = transaction_id
        self.undo_log_head = None

    def write_undo_log(self, table_name, row_id, old_value):
        entry = UndoLogEntry(self.transaction_id, table_name, row_id, old_value)
        entry.prev = self.undo_log_head
        self.undo_log_head = entry

    def rollback(self, database):
        current = self.undo_log_head
        while current:
            database.update(current.table_name, current.row_id, current.old_value)
            current = current.prev
        print(f"Transaction {self.transaction_id} rolled back successfully.")

# 模拟数据库操作
class Database:
    def __init__(self):
        self.data = {"Account A": 500, "Account B": 200}

    def read(self, account_name):
        return self.data[account_name]

    def update(self, account_name, new_value):
        self.data[account_name] = new_value
        print(f"Updated {account_name} to {new_value}")

# 示例用法
database = Database()
transaction = Transaction(123)

# 开始事务
old_value_A = database.read("Account A")
transaction.write_undo_log("Account A", "balance", old_value_A)
database.update("Account A", 400)  # 扣款

old_value_B = database.read("Account B")
transaction.write_undo_log("Account B", "balance", old_value_B)
database.update("Account B", 300)  # 加款

# 模拟发生错误，需要回滚
print("Simulating an error, rolling back...")
transaction.rollback(database)

print("Database state after rollback:", database.data)

Redo Log：重做的保障

Redo Log 用于在系统崩溃后，将已经提交的事务重新执行一遍，以保证持久性。它记录了事务对数据修改后的值（new value）。当系统崩溃重启后，数据库系统会扫描Redo Log，将所有已提交的事务重新应用到数据库中，从而恢复到崩溃前的状态。

Redo Log的工作原理

记录修改后的状态: 在事务修改数据后，数据库系统会将修改后的数据值写入Redo Log。这个过程称为"After Image"。
先写日志 (Write-Ahead Logging, WAL): Redo Log 必须在数据真正写入磁盘之前先写入持久化存储（例如，磁盘）。这是Redo Log能够保证持久性的关键。
事务提交: 事务提交时，Redo Log 会被强制刷新到磁盘，确保日志记录已经持久化。
崩溃恢复: 系统崩溃重启后，数据库系统会扫描Redo Log，找到所有已提交但尚未应用到数据库的数据修改，并重新执行这些修改。

Redo Log示例

沿用之前的银行转账例子：

账户A的余额：500元
账户B的余额：200元

下面是一个简化的Redo Log记录：

事务ID	操作	对象	修改后的值 (After Image)
123	UPDATE	Account A	400
123	UPDATE	Account B	300

假设在事务提交后，但Account A的数据修改尚未写入磁盘时，系统崩溃。重启后，系统会扫描Redo Log，发现事务123已提交，但Account A的值仍然是500。于是，系统会根据Redo Log的记录，将Account A的值更新为400，完成数据的恢复。

Redo Log的存储方式

Redo Log通常以顺序写入的方式存储，因为顺序写入的效率比随机写入高得多。

代码示例（伪代码）

class RedoLogEntry:
    def __init__(self, transaction_id, table_name, row_id, new_value):
        self.transaction_id = transaction_id
        self.table_name = table_name
        self.row_id = row_id
        self.new_value = new_value

class RedoLog:
    def __init__(self, log_file):
        self.log_file = log_file

    def write_log(self, entry):
        # 将 RedoLogEntry 写入到日志文件
        with open(self.log_file, "a") as f:
            f.write(f"{entry.transaction_id},{entry.table_name},{entry.row_id},{entry.new_value}n")

    def recover(self, database):
        # 从日志文件中读取 RedoLogEntry，并重做事务
        with open(self.log_file, "r") as f:
            for line in f:
                transaction_id, table_name, row_id, new_value = line.strip().split(",")
                database.update(table_name, row_id, int(new_value))  # 假设 new_value 是整数
        print("Recovery complete.")

# 模拟数据库操作
class Database:
    def __init__(self):
        self.data = {"Account A": 500, "Account B": 200}

    def read(self, account_name):
        return self.data[account_name]

    def update(self, account_name, new_value):
        self.data[account_name] = new_value
        print(f"Updated {account_name} to {new_value}")

# 示例用法
redo_log = RedoLog("redo.log")
database = Database()

# 模拟事务
transaction_id = 123
redo_log.write_log(RedoLogEntry(transaction_id, "Account A", "balance", 400))
database.update("Account A", 400)

redo_log.write_log(RedoLogEntry(transaction_id, "Account B", "balance", 300))
database.update("Account B", 300)

# 模拟系统崩溃
print("Simulating a crash...")
database.data["Account A"] = 500 # 模拟 Account A 的更改没有刷到磁盘

# 恢复
print("Starting recovery...")
database = Database() # 重新初始化数据库，模拟从磁盘加载
redo_log.recover(database)

print("Database state after recovery:", database.data)

Write-Ahead Logging (WAL)的重要性

Write-Ahead Logging (WAL) 是 Redo Log 机制的核心。它保证了在将数据修改写入磁盘之前，Redo Log 必须先写入磁盘。这样，即使系统在数据写入磁盘之前崩溃，Redo Log 中仍然保存了已提交事务的修改记录，从而可以在重启后恢复数据。

WAL 的优势：

提升性能: WAL 允许数据库系统将数据修改先写入内存缓冲区，然后批量写入磁盘，从而减少了磁盘I/O次数，提高了性能。
保证持久性: WAL 确保了即使系统崩溃，已提交的事务仍然可以被恢复。

两阶段提交（Two-Phase Commit, 2PC）与 Redo/Undo Log

在分布式事务中，为了保证多个节点上的事务具有原子性，通常会使用两阶段提交协议（2PC）。 Redo Log 和 Undo Log 在 2PC 中也扮演着重要的角色。

准备阶段 (Prepare Phase): 事务协调者 (Coordinator) 向所有参与者 (Participant) 发送准备请求，询问是否可以提交事务。参与者执行事务，并将 Redo Log 和 Undo Log 写入磁盘，然后向协调者返回准备结果。
提交阶段 (Commit Phase): 如果所有参与者都返回准备成功，协调者向所有参与者发送提交请求。参与者将事务提交，并释放资源。如果任何一个参与者返回准备失败，协调者向所有参与者发送回滚请求。参与者根据 Undo Log 回滚事务。

Redo/Undo Log与ACID特性的关系

ACID特性	Redo Log	Undo Log	作用
原子性 (Atomicity)		保证事务回滚	确保事务要么全部执行，要么全部不执行
一致性 (Consistency)		保证事务回滚	确保数据库从一个一致性状态转换到另一个一致性状态
隔离性 (Isolation)			Redo/Undo Log 主要保障原子性和持久性，隔离性主要通过锁机制实现
持久性 (Durability)	保证事务重做		确保已提交的事务不会丢失

Redo Log和Undo Log的常见问题

日志空间不足: 如果Redo Log或Undo Log的空间不足，可能会导致事务无法执行。需要定期清理过期日志。
日志写入性能: 频繁的日志写入会影响数据库性能。可以使用批量写入、异步写入等技术来优化日志写入性能。
恢复时间: 系统崩溃后，恢复时间取决于Redo Log的大小。需要合理控制Redo Log的大小，并优化恢复算法。

总结一下：Redo Log和Undo Log是数据库崩溃恢复的基石

总的来说，Redo Log和Undo Log是保证数据库事务ACID特性的关键机制。Undo Log负责回滚未提交的事务，确保原子性；Redo Log负责重做已提交的事务，确保持久性。Write-Ahead Logging是实现持久性的核心技术。理解和掌握Redo Log和Undo Log的工作原理，对于构建可靠的数据库系统至关重要。

Redo Log与Undo Log：崩溃恢复中的ACID卫士

发表回复 取消回复

发表回复取消回复