一个可视化数据流平台，做大数据的看过来

MySQL Double Write Buffer是什么？架构是怎样的？为什么能保证崩溃恢复...

InnoDB 是 MySQL 中一种常用的事务性存储引擎，它具有很多优秀的特性。其中，Doublewrite Buffer 是 InnoDB 的一个重要特性之一。

本文将介绍Doublewrite Buffer的原理和应用。

• 为什么需要 Doublewrite Buffer？
• Doublewrite Buffer 的架构设计和实现原理是什么？
• Redo Log 与 不是可以实现崩溃恢复了码？为何还需要 Doublewrite Buffer？

为什么需要 Doublewrite Buffer

InnoDB 页大小为 16KB，而操作系统（如 Linux）页大小为 4KB，单次写入需拆分 4 个 OS 页。

可以使用如下命令查看 MySQL 的 Page 大小：

SHOW VARIABLES LIKE 'innodb_page_size';

MySQL 程序是跑在 Linux 操作系统上的，需要跟操作系统交互，所以 MySQL 中一页数据刷到磁盘，要写 4 个文件系统里的页。

图片

需要注意的是，这个操作并非原子操作，比如我操作系统写到第二个页的时候，Linux 机器断电了，这时候就会出现问题了。

造成”页数据损坏“。并且这种”页数据损坏“靠 redo 日志是无法修复的。

Redo log 中记录的是对页的物理操作，而不是页面的全量记录，而如果发生 partial page write（部分页写入）问题时，出现问题的是未修改过的数据，此时重做日志(Redo Log)无能为力。

Doublewrite Buffer 的出现就是为了解决上面的这种情况，虽然名字带了 Buffer，但实际上 Doublewrite Buffer 是内存+磁盘的结构。

Doublewrite Buffer 是一种特殊文件 flush 技术，带给 InnoDB 存储引擎的是数据页的可靠性。

它的作用是，在把页写到数据文件之前，InnoDB 先把它们写到一个叫 doublewrite buffer（双写缓冲区）的共享表空间内，在写 doublewrite buffer 完成后，InnoDB 才会把页写到数据文件的适当的位置。

如果在写页的过程中发生意外崩溃，InnoDB 在稍后的恢复过程中在 doublewrite buffer 中找到完好的 page 副本用于恢复。

架构设计

Doublewrite Buffer 采用 内存+磁盘双层结构，关键组件如下：

图片

内存结构

• 容量固定为 128 个页（2MB），每个页 16KB。
• 数据页刷盘前，通过 memcpy 拷贝至内存 Doublewrite Buffer。

磁盘结构

• 位于系统表空间（ibdata），分为 2 个区（extent1/extent2），共 2MB。
• 数据以 顺序写 方式写入，避免随机 I/O 开销。

工作流程如下图所示：

图片

如上图所示，当有数据修改且页数据要刷盘时：

1. 第一步：记录 Redo log。
2. 第二步：脏页从 Buffer Pool 拷贝至内存中的 Doublewrite Buffer。
3. 第三步：Doublewrite Buffer 的内存里的数据页，会 fsync 刷到 Doublewrite Buffer 的磁盘上，分两次写入磁盘共享表空间中(连续存储，顺序写，性能很高)，每次写 1MB；
4. 第四步：Doublewrite Buffer 的内存里的数据页，再刷到数据磁盘存储 .ibd 文件上（离散写）；

时序图如下：

图片

崩溃恢复

如果第三步前，发生了崩溃，可以通过第一步记录的 Redo log 来恢复。

如果第三步完成后发生了崩溃， InnoDB 存储引擎可以从共享表空间中的 Double write 中找到该页的一个副本，将其复制到独立表空间文件，再应用 Redo log 恢复。

在正常的情况下，MySQL 写数据页时，会写两遍到磁盘上，第一遍是写到 doublewrite buffer，第二遍是写到真正的数据文件中，这就是“Doublewrite”的由来。

Doublewrite Buffer 通过 两次写 机制，在内存和磁盘间构建冗余副本，成为 InnoDB 保障数据完整性的基石。

其架构设计平衡了性能与可靠性，尤其在高并发或异常宕机场景下表现突出。

最近码哥发现一个可视化数据流平台我的粉丝扶着门应该也有一些小伙伴做大数据相关的工作吧。

• 产品支持任意并行、支持流批任务一体化。
• 数据流支持版本控制。
• 支持分布式、多实例、异常自动容错。
• 完善的异常告警机制。
• 支持数据权限配置。

项目官网：https://shaiwz.com/home  前端代码地址：https://gitee.com/shaiwz/data-platform-front-open  项目展示地址：http://dataplatform.cn/login

大家可以体验一把。我简单体验了一下，给大家介绍下它的功能，给有需要的小伙伴。

开搞！！

基础架构

先看看他的基础架构设计。

支持任意节点缩扩容，当资源使用率低的时候支持动态减少节点节约成本，当遇到大促等活动服务压力过大时增加节点数提高数据处理吞吐量。

none

人靠衣装，佛靠金装；先看看 UI 操作是否人性化，页面是否美观。

首页

综合看板，方便查看系统运行情况，数据一致性，数据源健康率，以及告警信息等。

none

看起来还行，继续看其他的 UI 页面。

数据流统计

用来监控数据流的运行情况，数据流的运行情况，以及数据流服务器的压力。

none

点击处理器、或者内存时展示服务器运行信息

none

同时可以在服务监控中看具体的服务器信息

none

查询模板统计

用来查看查询模板的调用情况，查询服务器运行信息

none

数据管理

如果页面好看，还不足以吸引我，内核必须要硬，真男人不仅要颜值高，还要持久，硬核！

数据流

支持随意构建数据流向，拖拖拽拽完成数据同步，清洗，过滤等任何操作，全程不需要写任何代码。

数据流列表

查看有哪些数据流任务

none

数据流画布

支持在一个画布里面完成数据同步，清洗，过滤、报表数据生成等任何操作，全程不需要写任何代码。

none

发布服务器资源可控，自动容错，节点支持动态扩容，服务节点越多，性能越好。支持多版本，支持回滚。

none

数据流实时运行日志

none

数据流发布记录

在这里可以查看历史版本流程、以及支持回退到历史版本。

图片

数据源

支持若干种数据源，插件方式，便于扩展其他数据源

数据源创建

none

数据源控制台

不同数据源支持不同的控制台，例如 MySQL、StarRocks、Doris、Oracle 等控制台样式如下

none

Kafka 控制台

none

none

ElasticSearch 控制台

none

等等其他控制台

数据对齐

通过页面简易配置即可能完成两个任意数据源、不同类型数据源数据表、索引等一致性校验，告警、并支持自动化修复！

数据对齐列表

这里方便查看有哪些对齐任务

none

数据对齐创建

配置何时触发，以及策略对齐策略：数量一致、内容一致、随机数量，对比时间范围等等配置。

none

数据对齐日志

开源快速方便查看任务的运行情况

none

数据对齐日志详情

针对某次对齐任务，不一致的数据快速查看，并提示出差异字段等。

none

查询模板

通过查询模板可以快速创建查询任务，支持多种数据源。不用后端开发再去编写查询报表、对外提供数据查询接口。

查询模板列表

支持版本控制、密钥、权限配置等

none

查询模板创建

支持动态条件、分表。

none

扩展支持限流、记录日志、缓存等配置

none

预览页面有示例文档，以及快速测试，测试没问题可以点击发布，外部服务即可调用。

none

查询模板调用日志

支持完善的日志记录，日志可跟踪。

图片

查询日志详情

none