数据库事务原理

数据库事务日志（Redo Log/Undo Log）的作用与恢复机制

上周我查看了数据库。
RedoLog和UndoLog非常重要。

RedoLog主要管理持久化。
例如，2 02 3 年1 0月1 0日下午3 点，我查看了一个特定的表。
在事务提交之前，首先修改BufferPool内存中的数据。
同时RedoLog记录了这个过程，例如：例如。
“将表t第3 行的ID更改为1 00”。
必须首先将此 RedoLog 条目写入磁盘日志文件。
只有成功清空硬盘，才算交易真正提交。

例如，如果服务器突然宕机，上周五晚上系统就崩溃了。
重启后，数据库会搜索最近的检查点。
然后一一读取RedoLog文件。
比如我发现记录了将ID改为1 00的操作。
数据页被重新创建。
这称为“前向恢复”。
顺序写入日志文件比随机写入磁盘要快得多。

UndoLog有多种功能。
主要负责原子性和隔离性。
例如，上周二早上，事务A想要更改数据。
在进行更改之前，UndoLog 首先记录原始值。
假设更改是“将 ID 更改为 1 00”。
UndoLog 存储“it was 9 9 ”。
如果事务A执行失败或者用户手动回滚。
数据库根据UndoLog将ID改回9 9
UndoLog 还支持 MVCC。
例如，事务B在2 02 3 年1 1 月5 日下午读取数据，事务A尚未提交。
交易B看到的可能是历史版本9 9 交易A提交了，但是交易B仍然可以看到9 9 这就是版本链。
读取已提交的隔离级别并读取已提交的版本。
可重复读隔离级别读取事务开始时的版本。
旧的和无法使用的版本会在后台慢慢删除。

RedoLog 和 UndoLog 一起使用。
在崩溃恢复期间，RedoLog 负责恢复已提交的事务。
UndoLog 负责撤消未提交的事务。
例如，它在上周日晚上和重新启动后崩溃了。
RedoLog 更改了提交的内容。
UndoLog 更改回未提交的日志。

算了。
大概就是这样。
由你决定。

shardingsphere分布式事务实现原理

ShardingSphere的本地事务模式直接利用数据库的ACID特性，适合简单的数据库应用。

XA方法采用通过数据库提交的两个阶段，非常复杂，适合大型项目。

WHISTLE方法适用范围广，简单有效，但存在一定的延迟。

选择分布式事务时，必须考虑应用程序的复杂性和性能要求。
你必须为自己考虑。