1.详解 MySQL 的源码 undo log
2.MySQL 核心模块揭秘 | 12 期 | 创建 savepoint
3.PostgreSQL · 源码分析 · 回放分析（一）
4.重读Redux源码的感悟

详解 MySQL 的 undo log

       详解MySQL的undo log

       undo log是InnoDB引擎中的一种关键日志，它在事务修改数据记录前，源码先行保存该记录的源码原始状态（before image），以便在修改过程中遇到错误时恢复原始数据或允许其他事务读取。源码undo log的源码两个主要作用在于提供事务的回滚能力和支持并发读取。

       在事务执行时，源码rsmsfield指标源码以下四种操作会生成undo log：插入、源码更新、源码删除和选择。源码在MySQL的源码不同版本中，undo log的源码存储方式也有所变化。在早期版本中，源码undo log与系统表空间共存于同一个表空间内，源码直到MySQL 5.6.3版本引入了将undo log表空间独立出来的源码特性。这一特性在MySQL 5.7版本中得到进一步强化，源码引入了在线truncating undo tablespace功能。MySQL 8.0版本进一步改进undo log机制，使其更易于管理和优化性能。

       undo log主要储存在单独的undo tablespace中，这个表空间定义了回滚段（rollback segments），用于存放undo log。undo tablespace的结构通过源代码中的定义得以揭示，其中包括了用于管理回滚段的结构体。回滚段进一步管理着Rollback Segment Header Page，以确保数据的高效管理和回滚操作。

       undo log可以分为insert undo log和update undo log两种类型。对于insert操作，undo log记录插入数据的ID，以便在事务回滚时精确删除；对于update操作，undo log记录修改前的数据，回滚时只需反向更新。而对于delete和select操作，由于它们不涉及数据的修改，因此不需要undo log来支持回滚。

       undo log的文档系统源码处理逻辑复杂，但通过构建undo log链条，可以高效地实现事务的回滚。当事务开始时，会记录所有修改前的数据到undo log中。当事务提交后，这些undo log可能仍保留在系统中，以备在需要时执行回滚操作。在事务执行期间，其他事务可以读取undo buffer缓存中的数据，从而实现并发读取。当事务回滚时，系统会从undo buffer中读取数据，而不是直接从磁盘读取，从而提高了性能和效率。

       总的来说，undo log在MySQL中扮演着至关重要的角色，它不仅保证了事务的原子性和一致性，还支持并发读取，提高了数据库的性能和可靠性。理解undo log的工作原理对于深入掌握MySQL的事务处理机制至关重要。

MySQL 核心模块揭秘 | 期 | 创建 savepoint

       回滚操作，除了回滚整个事务，还可以部分回滚。部分回滚，需要保存点（savepoint）的协助。本文我们先看看保存点里面都有什么。

       作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 MySQL 和 OceanBase 源码。 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源

       本文基于 MySQL 8.0. 源码，存储引擎为 InnoDB。word源码解析

       InnoDB 的事务对象有一个名为undo_no 的属性。事务每次改变（插入、更新、删除）某个表的一条记录，都会产生一条 undo 日志。这条 undo 日志中会存储它自己的序号。这个序号就来源于事务对象的 undo_no 属性。

       也就是说，事务对象的 undo_no 属性中保存着事务改变（插入、更新、删除）某个表中下一条记录产生的 undo 日志的序号。

       每个事务都维护着各自独立的 undo 日志序号，和其它事务无关。

       每个事务的 undo 日志序号都从 0 开始。事务产生的第 1 条 undo 日志的序号为 0，第 2 条 undo 日志的序号为 1，依此类推。

       InnoDB 的 savepoint 结构中会保存创建 savepoint 时事务对象的 undo_no 属性值。

       我们通过 SQL 语句创建一个 savepoint 时，server 层、binlog、InnoDB 会各自创建用于保存 savepoint 信息的结构。

       server 层的 savepoint 结构是一个SAVEPOINT 类型的对象，主要属性如下：

       binlog 的 savepoint 结构很简单，是一个 8 字节的整数。这个整数的值，是创建 savepoint 时事务已经产生的 binlog 日志的字节数，也是接下来新产生的 binlog 日志写入 trx_cache 的 offset。

       为了方便介绍，我们把这个整数值称为binlog offset。

       InnoDB 的 savepoint 结构是一个trx_named_savept_t 类型的对象，主要属性如下：

       创建 savepoint 时，server 层会分配一块 字节的内存，除了存放它自己的注册页 源码 SAVEPOINT 对象，还会存放 binlog offset 和 InnoDB 的 trx_named_savept_t 对象。

       server 层的 SAVEPOINT 对象占用这块内存的前 字节，InnoDB 的 trx_named_savept_t 对象占用中间的 字节，binlog offset 占用最后的 8 字节。

       客户端连接到 MySQL 之后，MySQL 会分配一个专门用于该连接的用户线程。

       用户线程中有一个m_savepoints 链表，用户创建的多个 savepoint 通过 prev 属性形成链表，m_savepoints 就指向最新创建的 savepoint。

       server 层创建 savepoint 之前，会按照创建时间从新到老，逐个查看链表中是否存在和本次创建的 savepoint 同名的 savepoint。

       如果在用户线程的 m_savepoints 链表中找到了和本次创建的 savepoint 同名的 savepoint，需要先删除 m_savepoints 链表中的同名 savepoint。

       找到的同名 savepoint，是 server 层的SAVEPOINT 对象，它后面的内存区域分别保存着 InnoDB 的 trx_named_savept_t 对象、binlog offset。

       binlog 是个老实孩子，乖乖的把 binlog offset 写入了 server 层为它分配的内存里。删除同名 savepoint 时，不需要单独处理 binlog offset。

       InnoDB 就不老实了，虽然 server 层也为 InnoDB 的 trx_named_savept_t 对象分配了内存，但是 InnoDB 并没有往里面写入内容。

       事务执行过程中，用户每次创建一个 savepoint，InnoDB 都会创建一个对应的 trx_named_savept_t 对象，并加入 InnoDB 事务对象的 trx_savepoints 链表的末尾。

       因为 InnoDB 自己维护了一个存放 savepoint 结构的链表，server 层删除同名 savepoint 时，InnoDB 需要找到这个链表中对应的 savepoint 结构并删除，流程如下：

       InnoDB 从事务对象的 trx_savepoints 链表中删除 trx_named_savept_t 对象之后，server 层接着从用户线程的担保网源码 m_savepoints 链表中删除 server 层的SAVEPOINT 对象，也就连带着清理了 binlog offset。

       处理完查找、删除同名 savepoint 之后，server 层就正式开始创建 savepoint 了，这个过程分为 3 步。

       第 1 步，binlog 会生成一个 Query_log_event。

       以创建名为test_savept 的 savepoint 为例，这个 event 的内容如下：

       binlog event 写入 trx_cache 之后，binlog offset 会写入 server 层为它分配的 8 字节的内存中。

       第 2 步，InnoDB 创建 trx_named_savept_t 对象，并放入事务对象的 trx_savepoints 链表的末尾。

       trx_named_savept_t 对象的 name 属性值是 InnoDB 的 savepoint 名字。这个名字是根据 server 层为 InnoDB 的 trx_named_savept_t 对象分配的内存的地址计算得到的。

       trx_named_savept_t 对象的savept 属性，是一个 trx_savept_t 类型的对象。这个对象里保存着创建 savepoint 时，事务对象中 undo_no 属性的值，也就是下一条 undo 日志的序号。

       第 3 步，把 server 层的 SAVEPOINT 对象加入用户线程的 m_savepoints 链表的尾部。

       server 层会创建一个SAVEPOINT 对象，用于存放 savepoint 信息。

       binlog 会把binlog offset 写入 server 层为它分配的一块 8 字节的内存里。

       InnoDB 会维护自己的 savepoint 链表，里面保存着trx_named_savept_t 对象。

       如果 m_savepoints 链表中存在和本次创建的 savepoint 同名的 savepoint， 创建新的 savepoint 之前，server 层会从链表中删除这个同名的 savepoint。

       server 层创建的 SAVEPOINT 对象会放入m_savepoints 链表的末尾。

       InnoDB 创建的 trx_named_savept_t 对象会放入事务对象的trx_savepoints 链表的末尾。

PostgreSQL · 源码分析 · 回放分析（一）

       在数据库运行中，可能遇到非预期问题，如断电、崩溃。这些情况可能导致数据异常或丢失，影响业务。为了在数据库重启时恢复到崩溃前状态，确保数据一致性和完整性，我们引入了WAL（Write-Ahead Logging）机制。WAL记录数据库事务执行过程，当数据库崩溃时，利用这些记录恢复至崩溃前状态。

       WAL通过REDO和UNDO日志实现崩溃恢复。REDO允许对数据进行修改，UNDO则撤销修改。REDO/UNDO日志结合了这两种功能。除了WAL，还有Shadow Pagging、WBL等技术，但WAL是主要方法。

       数据库内部，日志管理器记录事务操作，缓冲区管理器负责数据存储。当崩溃发生，恢复管理器读取事务状态，回放已提交数据，回滚中断事务，恢复数据库一致性。ARIES算法是日志记录和恢复处理的重要方法。

       长时间运行后崩溃，可能需要数小时甚至数天进行恢复。检查点技术在此帮助，将脏数据刷入磁盘，记录检查点位置，确保恢复从相对较新状态开始，同时清理旧日志文件。WAL不仅用于崩溃恢复，还支持复制、主备同步、时间点还原等功能。

       在记录日志时，WAL只在缓冲区中记录，直到事务提交时等待磁盘写入。LSN（日志序列号）用于管理，只在共享缓冲区中检查。XLog是事务日志，WAL是持久化日志。

       崩溃恢复中，checkpointer持续做检查点，加快数据页面更新，提高重启恢复速度。在回放时，数据页面不断向前更新，直至达到特定LSN。

       了解WAL格式和包含信息有助于理解日志内容。PG社区正在实现Zheap特性，改进日志格式。WAL文件存储在pg_wal目录下，大小为1GB，与时间线和LSN紧密关联。事务日志与WAL段文件相关联，根据特定LSN可识别文件名和位置。

       使用pg_waldump工具可以查看日志内容，理解一次操作记录。日志类型包括Standby、Heap、Transaction等，对应不同资源管理器。PostgreSQL 包含种资源管理器类型，涉及堆元组、索引、序列号操作。

       标准记录流程包括：读取数据页面到frame、记录WAL、进行事务提交。插入数据流程生成WAL，复杂修改如索引分裂需要记录多个WAL。

       崩溃恢复流程从控制文件中获取检查点位置，严格串行回放至崩溃前状态。redo回放流程与记录代码高度一致。在部分写问题上，FullPageWrite（FPW）策略记录完整数据页面，防止损坏。WAL错误导致部分丢失不影响恢复，数据库会告知失败。磁盘静默错误和内存错误需通过冗余校验解决。

       本文总结了数据库崩溃恢复原理，以及PostgreSQL日志记录和崩溃恢复实现。深入理解原理可提高数据库管理效率。下文将详细描述热备恢复和按时间点还原（PITR）方法。

重读Redux源码的感悟

       大道至简的createStore

       创造理解的%在createStore.js中体现，剩下%涉及中间件，整体来看软件开发追求高内聚，内耦合，以简洁面世。Redux源码由9个文件构成，包含中间件的代码。整体而言，Redux的深层含义超出了源码大小所能体现，业界常言“Redux是百行代码千行文档”，强调其复杂性。

       回到createStore.js，剥离中间件影响，仅留下核心代码骨架。最终返回的对象即store，提供了常用API。通过观察者模式或发布/订阅模式理解此框架，但要认识到Redux并非仅此，它结合现代前端开发与函数式编程，带来限制与便利，如纯函数要求、测试便利性、功能解耦及性能优化。

       实现撤销功能（undo）示例，通过高阶reducer存储过往状态值，结合Redux实现撤销与重做。函数式编程的FP特性，使实现变得可能。

       combineReducer利用闭包概念，接收多个reducer，生成单个reducer，可遍历执行所有reducer。若两个reducer同时处理相同type的action，它们都会执行更新状态。此特性可能带来冲突，需合理命名以避免问题。

       使用CLI工具搭建开发环境可能耗时，codesandbox.io提供多种框架支持及快速加载依赖，适合灵感突发时快速测试代码。

       在命名Action时，采用namespace前缀（如/或@）可避免重复，有助于清晰管理状态与减少冲突。

       compose方法实现多个方法串联执行，功能强大，易于实现并用于中间件处理。在Redux中，中间件处理Action，与服务器端处理request、response的Koa或Express不同，但核心原理相似，利用compose方法串联功能。

       中间件本质为方法代理，通过增强原方法执行前后添加操作，实现AOP。在Redux中，中间件位于store.dispatch之前，通过代理dispatch实现场景扩展与功能增强。理解中间件需关注enhancer参数及createStore方法传递，最后实现store与中间件串联。

       以redux-thunk为例，底层参数接收中间件API，只传递store的getState和dispatch方法，遵循特定逻辑处理action，提供方法执行选择与状态管理。中间件使用时需阅读文档，理解其规范与实现细节。

       综上，Redux源码展示了现代前端开发与函数式编程的结合，从createStore、combineReducer到中间件，提供了高效状态管理与功能扩展。理解其核心概念与实现机制，有助于深入应用与开发。