数据库备份速度提升27倍：去哪儿网如何构建零感知、高性能的备份恢复系统?

# 一分钟精华速览 #

去哪儿网的老备份恢复系统面临备份成功率不高、备份操作影响业务运行、以及缺乏对备份文件有效性验证等问题。为此，去哪儿网通过打造高性能、高可用、高扩展的备份恢复系统，实现流式备份、智能限速与定制化需求。最终，新系统实现了备份速度提升 27 倍至 2TB/小时，恢复速度提升 10 倍至 1TB/小时，极大提升了数据安全性和恢复效率。详细的解决策略和方法，请参阅文章正文。

作者介绍

去哪儿网资深DBA——钱芳园

TakinTalks 稳定性社区专家团成员，去哪儿网资深 DBA，多年运维 MySQL、Redis 运维和数据库平台开发经验。在去哪儿开发新一代数据库管控平台，支撑起业务对平台高性能、高可靠性的要求，目前专注于数据库管控平台开发。

温馨提醒：本文约8500字，预计花费12分钟阅读。

后台回复 “交流” 进入读者交流群；回复“Q112”获取课件；

背景

数据库备份对于防止数据丢失至关重要。无论是由于业务操作失误、数据被意外删除，还是数据库系统故障，备份都是数据恢复的关键。然而，尽管去哪儿网的老系统经过了多代的迭代和修补，一些根本性问题仍未得到解决。

去哪儿网的老系统分为两个部分：一部分由我们自己维护，另一部分由 OPS 团队管理。备份过程依赖于 MySQL 服务器，系统会定期执行备份任务，并将备份数据发送到中转服务器。之后，数据被打包上传到 MFS 存储系统。OPS 团队会进一步加密、上传这些数据，并最终存储到对象存储服务中。

这个流程虽然稳定运行多年，但问题逐渐显现。我们过于依赖 SSH，网络波动常常导致备份任务失败。随着 MySQL 数据量的增长，中转服务器的性能成为了限制因素，有时甚至无法在一个备份周期内完成备份。此外，备份管理并不全面，一旦数据上传后，工作就结束了，而恢复过程也完全需要手动执行，效率非常低。

鉴于这些挑战，我们决定开发一个全新的备份恢复系统，旨在解决这些问题，同时适应未来的新需求。接下来，我将详细说明新系统设计及其效果。

一、起初去哪儿面临哪些痛点和难点？

1.1 项目痛点

让我们通过一个例子来理解建设之初的痛点。

业务在执行过程中可能发生一些误操作，比如在数据库中对索引进行修改时，由于不太了解索引和唯一索引之间的区别，错误地将普通索引更改为唯一索引，导致大量数据丢失。这种情况下，业务可能就无法正常访问数据了。如果此时这部分数据在其他地方没有备份，那么就需要用备份进行数据恢复。

恢复过程通常涉及 OPS 团队的协助，他们会协助将备份文件下载下来，先进行解密，然后再将文件传输到 DBA 的服务器上。接下来，DBA 将对文件进行解压，应用日志，启动数据库，导入需要的日志，并将所需的数据导入到线上环境。最后，我们会通知业务部门，数据已经恢复完成。整个过程比较耗时的部分主要是文件的下载、解密和传输环节。我们之前处理过一个 2TB 的备份恢复案例，整个过程耗时接近一天，这对业务的影响是非常大的。

1.2 项目难点

我们项目团队当时面临的问题是如何能承接住较大的数据库备份需求。

如果选择修复：在现有的小系统上进行小修小补，可能难以解决一些根本性的问题。如果进行大的改动，如替换存储系统，则需要进行大量的测试，耗时较长。

如果选择重构：虽然能够解决根本问题，但这本身也是一个耗时较长、成本较高的过程。

我们不能简单地丢弃老系统，对于一些小的 bug，仍然需要修复，除非是那些非常严重以至于无法使用的 bug。即便如此，这样的修复工作成本也是相对较高的。因此，我们需要在维护现有系统稳定的同时，寻找更有效的方法来解决面临的挑战。

二、数据库备份恢复系统需要哪些关键能力？

2.1 搭建一个新平台

随着项目的推进，我们意识到需要一个全新的平台来满足我们的需求。我们决定将备份恢复系统作为新平台的第一个项目。这个新平台的架构设计非常关键，它决定了我们未来的发展。

2.1 图1–新平台架构设计

在新平台架构中，位于最左边的是 Server 和 Meta。Server 是所有模块的管控节点，负责整个系统的管理和协调。而 Meta 则是的元数据中心，它包含了系统的核心数据和配置信息。这两个组件是独立于整个平台架构之外的，它们构成了整个平台的基础。

在架构的最上层有展示平台，包括 Console、Web 界面和 Phone 页面，这些用户界面使得用户可以方便地访问和管理我们的服务。

API 层作为接入层，负责处理外部请求，向展示平台提供所需的数据，并进行转发和验证等操作。它确保了平台的安全性和数据的准确性。

接下来是高级服务层，这里集成了报告、分析和资源管理等核心功能，它们为用户提供了强大的数据支持和服务。

再往下是基础服务层，包括高可用性（HA）、监控和备份恢复服务。备份库作为基础服务的一部分，负责存储和管理备份数据。

在我们的架构中，Agent 负责管控 Plugin，每个节点上都部署 Agent。插件层是执行具体任务的地方，每个 Plugin 对应一组特定的功能。我们制定了一套规则，上层组件可以调用下层组件提供的服务，但下层组件不能随意调用上层组件，确保了架构的稳定性和可控性。

我们致力于打造一个更智能、更专业、更全面的平台。正是在这个新平台的基础上，我们开始构建起一个全新的数据库备份恢复系统。

2.2 建设目标

我们对下一代备份系统的整体要求比较高，除了要求高性能、高可用性、高扩展性之外，还需要满足一些定制化的需求。

首先，我们要求系统能够做到流式备份，这意味着需要去除对中转服务器的依赖。我们希望能够直接将数据传输到对应的存储系统上。这样，即使 MySQL 扩容，也不会依赖于中转服务器，因为我们已经去除了中转服务器这一环节。

其次，我们希望实现智能限速。在高性能的服务器上，传输速度应该会比较快；而在性能较低的服务器上，传输速度可能会比较低。我们需要系统能够自动适配不同的服务器性能，而不需要人工进行设置。

高可用性方面，我们要求每一个模块都需要多节点部署。为了防止机房级别的故障，还需要支持部署到至少两个机房。

此外，为了实现高扩展性，我们要求节点做到无状态，这样在扩展时就会更加方便。

最后，还需要进行一些定制化的工作，以适应整个平台的需求。例如，目前的平台主要支持 MySQL 5.6 和 5.7 版本，同时还有一小部分使用 8.0 版本。如果需要支持新的版本，比如 8.1 或 8.2，我们希望能够通过微小的改动甚至无需改动就能完美适配。

综上所述，我们的目标是构建一个高性能、高可用、高扩展的备份恢复系统，同时满足定制化的需求，以支持业务发展和数据保护。在这个目标的指引下，我们开始了新系统的设计和开发工作。

三、如何设计并实现快速备份恢复？

3.1 备份原理

简单来说，备份过程包括从源端读取数据流，经过通道进行操作，最后传输到存储系统上。以 MySQL 为例，源端就是 XtraBackup，它会读取 MySQL 中的数据，然后传输到 Plugin 上。在 Plugin 上，我们会进行一些必要的操作，最后将数据传输到对应的存储系统。

我们对备份系统有三项基本要求：压缩、加密和限速。这些要求在设计中是怎么样得到满足的呢？

首先，关于压缩，源端 XtraBackup 支持一些压缩算法，例如 QuickLZ 算法。而在 Plugin 层，可以采用更多种的压缩算法，如 gzip、LZ4、LZMA 以及 ZSTD 等，这些都是 Plugin 支持的压缩选项。但是压缩功能除了考虑压缩比还需要考虑压缩速度，由于 Xtrabackup 支持并行压缩，比 Plugin 拥有更高的压缩速度，所以我们选择使用 Xtrabackup 压缩的方式。

其次，对于加密，我们要求在数据上传到存储端之前完成加密操作。XtraBackup 提供了加密功能，但是只有 AES 算法，同时 Plugin 层也支持加密，提供了多种加密算法，包括 AES 以及不同密钥长度的选项，如 192 位、256 位等，以满足不同安全级别的需求。Xtrabackup 的加密算法可以满足我们的需求，同时其加密的速度也比 Plugin 高很多，所以我们也选择使用 Xtrabackup 进行加密。

最后，限速也是一个重要的考虑因素。在实际应用中我们发现，直接使用 XtraBackup 进行限速的效果并不理想。因此，我们选择在 Plugin 层实现限速，这样可以更灵活地根据单个任务的需求进行限速。

由于 Xtrabackup 实现了压缩和加密的功能，并且效率非常高效，故我们采用 Xtrabackup 的方案。但是部分数据库的备份传输工具没有压缩、加密、限速的功能，这时可以在 Plugin 中开启对应的功能，因此当前系统可以适配更多的数据库类型。

3.2 详细设计

3.2.1 详细设计-Xtrabackup 打包文件格式

XtraBackup 支持的备份速度非常高，这是如何实现的呢？其背后的原理在于它所使用的打包格式。在 XtraBackup 的 2.4 版本中，它支持两种格式：Tar 格式和 Xbstream 格式。

Tar 格式本质上是一个普通的 Tar 文件，它由一个 Header 开始，后面跟着一系列的文件，从文件 1 到文件 n，最后以一个 Tail 结束。如果使用 Tar 格式，我们可以使用 Linux 平台的 Tar 工具进行解压，支持 Tar 格式的工具比较多， Tar 格式也是一个通用的格式。

而 Xbstream 格式是 XtraBackup 自己定义的一种格式，它由许多 Xbstream 块组成。在这种格式中，每个 Xbstream 文件的前端是一个 Header，后端是一个 Tail，而中间则是 Xbstream 块。这些块是如何构成的呢？每当一个线程读取了一块文件，它就会将这个块组成一个 Xbstream 块。每个 Xbstream 模块包含了文件名、文件的 offset 以及一些校验信息，所有这些都被放置在一个 Xbstream 文件块中。然后，它会将所有的块组合起来，以便进行读取。比如，如果有 8 个线程，每个线程读取不同文件的一部分，一旦一个线程完成它的读取，它就会将数据放入通道中。如果开启了压缩和加密，通道中的压缩、加密线程会继续对 Xbstream 块进行并行压缩、并行加密。通过并行读取、并行压缩、并行加密，Xtrabackup 可以实现非常高的数据备份效率。

相比之下，使用 Tar 格式进行备份时，我们只能逐个文件地读取，这是一种单线程的读取方式，性能相对较低。这就是为什么 XtraBackup 能够支持高性能备份的原因之一。通过这种高效的读取和打包机制，XtraBackup 能够实现较高的备份速度，满足我们对备份系统的高性能需求。

3.2.2 详细设计-架构

我们的架构设计是整个备份系统的核心。

首先，我们有一个调度系统，它负责控制整个备份和恢复流程。调度系统通过触发器来定时生成备份和恢复任务，同时也负责调度这些任务的执行，并记录任务的调度信息和日志。

当备份任务被触发器定时生成后，它们会被写入到任务系统。任务系统的主要工作是选择需要进行备份或恢复的服务器实例，并将任务下发到对应的 Plugin。Plugin 不仅执行任务，还负责监控服务状态，进行负载保护。如果监控到服务器的负载如 CPU、IO 或网络带宽过高，Plugin 会终止任务以避免影响线上服务。

接下来，Plugin 会执行 Xtrabackup 进行备份，并从 Xtrabackup 的数据流中读取数据，并将这些数据传输到对应的存储系统。整个任务流程中的耗时较高阶段基本都是异步执行的。从调度系统到任务系统，再到 Plugin，这样的设计保证了执行任务的效率和系统的响应速度。

我们的调度系统和任务系统都是分布式的，这意味着每个组件都是独立且对等的。如果任何一个节点出现问题，其他节点可以立即接管其任务，确保服务不会中断，对业务的影响降到最低。此外，我们的备份设计是流式的，备份数据在传输过程中不会落盘，这样可以减少对线上服务的影响，保证了业务的连续性和稳定性。

3.2.3 详细设计-源端

3.2.3 图1-详细设计-源端

在源端，从 MySQL 和 Xtrabackup 并行读取数据，这个过程涉及到三个重要的参数：并行读取、并行压缩和并行加密。

首先，我们通过设置 parallel，Xtrabackup 可以并行读取文件来提高数据获取的效率。在读取的同时，设置 compress-threads 可以通过并行压缩参数来压缩数据，这样可以减少传输的数据量，提高传输效率。此外，还需要设置加密参数 encrypt-threads，提高加密效率，确保数据在传输过程中的安全性。一旦数据被加密，它就会被传输到 Plugin 中，Plugin 会进一步处理这些数据，然后再将其传输到对象存储系统中。

3.2.4 详细设计-通道&存储

Plugin 在不停地接收数据流后，会进行一系列的操作。

3.2.4 图1-详细设计-通道&存储

首先，Plugin 会将数据流分割成多个数据块，并将这些块存储在一个环形缓冲区中。这个缓冲区可以接收的块的数量是有限的，比如，可以设置为 3 个或 4 个，根据需要进行调整。一旦缓冲区中的数据块被读取完毕，它们就会被并行上传到对象存储中。上传完成后，这些块会在对象存储中被合并，形成一个完整的对象。

在数据块的上传过程中，如果缓冲区满了，Plugin 会暂停放入新的数据块，并等待上传线程从缓冲区中取走数据块。一旦缓冲区中有空间，Plugin 会继续存放新的数据块。这就是 Plugin 执行的基本流程。

3.2.5 详细设计-动态限速

我们的备份系统还要求实现智能限速。那么，我们是如何做到的呢？要想做到智能限速，首先需要做到可以动态调整限速。当 Plugin 从数据流读取数据时，它会计算读取这一块数据的实际耗时，然后与预期的耗时进行比较。如果实际耗时小于预期耗时，说明当前读取速度较快，系统会通过计算差值并适当地暂停（sleep），以降低读取速度。相反，如果实际耗时大于预期耗时，说明读取速度较慢，系统将不需要暂停，而是继续读取数据。这就是我们限速的原理。

3.2.5 详细设计-动态限速

关于动态限速，我们有一个专门的动态限速线程来负责这项工作。这个线程会根据我们预设的各种限速条件来调整备份速度，这些限速条件包括 CPU 使用率、IO 吞吐量、网络带宽以及 MySQL 的状态等多个方面。每个线程会针对这些限速项获取当前的数值。

以 IO 为例，假设我们设定的目标值是 100MB/s，而当前的 IO 吞吐量是 50MB/s，那么系统会计算出一个合适的速度，即当前的 50MB/s 到目标的 100MB/s 之间。如果当前的 IO 利用率远低于我们设定的阈值，系统会认为还有提升空间，可以逐步增加速度。理想的增速不是突变的，而是逐渐的，比如从 50MB/s 开始，逐步增加到 60MB/s、70MB/s，直至 100MB/s。

在这个过程中，系统会从所有监控的资源指标中选取一个最小的速度值作为最佳速度。如果 IO 当前是 50MB/s，而 CPU 已经达到了阈值，那么系统会选择以 CPU 的阈值为准，从而确定一个最小的最佳速度。一旦确定了最佳速度，系统就会据此调整期望的耗时（expect），以此来动态调整备份速度。

通过动态地调整期望耗时，我们能够实现对备份速度的动态限速，确保备份过程既高效又不会因为资源占用过高而影响其他服务。我们只需要在系统配置中设置好各项资源的阈值，比如 CPU 的使用率可以设定在 50%，如果当前仅使用了 30%，那样系统就可以提高速度。同样，对于 IO、网络带宽和其他资源也是如此，我们可以设定一个安全的范围，让系统根据实际情况动态调整。

3.2.6 详细设计-节点无状态

我们系统中所有的备份和恢复操作都是由一系列的任务组成的。例如，恢复验证过程包含多个任务，包括申请恢复服务器、执行恢复任务以及其他相关操作，这些任务都是联动执行的。任务是整个系统抽象出来的最小单元，我们对任务的要求需要具备原子性、唯一性和“状态”的要求。

原子性：这个是任务执行的基本要求，即所有的任务都支持幂等性。也就是说，一个任务执行一次和执行多次的结果是一样的。如果任务执行失败，它支持重试，这也是任务的一个重要特点。

唯一性：在任务系统中，我们有多个节点，但在同一时间点上，最多只有一个节点能够持有并执行一个任务。这是通过分布式锁来实现的，每个任务在不同阶段都会持有不同的分布式锁，只有持有相应锁的节点才能执行该任务。

“状态”：数据库会存储任务的状态，同时，我们的 Plugin 本地也会存储任务的结果。如果任务在执行过程中未能及时返回结果或者更新失败，系统可以从 Plugin 获取最终的任务结果，这样可以确保任务的幂等性，因为任务实际上已经完成。我们还引入了“易分区”的概念。在我们的调度系统中，不同的节点持有不同的触发器。如果一个节点异常，另一个节点会立即接管该触发器。这种设计意味着即使我们不能完全去除状态，但是我们也能通过分区来确保系统的稳定性和任务的连续性。当新增节点或有节点退出时，状态会自动进行迁移，这样的设计使得状态管理变得更加方便和灵活。

3.2.7 详细设计-定制化

在备份系统中，我们不仅提供了标准化的功能，还允许一定程度的定制化，以满足不同业务的需求。下面我将通过一个例子来说明我们是如何实现定制化的。

3.2.7.1 自定义清理策略

对于备份的频率，我们会根据集群的重要性定义不同的备份间隔，比如 P1 级别可能是每天备份一次，P2 级别可能是每 2 天备份一次，而 P3 级别可能是每 3 天备份一次，并且每个集群支持自定义间隔。针对清理策略，我们设计了一个称为“稀疏保留策略”的自定义清理策略。这个策略允许我们根据不同的时间段来保留不同数量的备份。如下图是某个集群的清理策略。

以上述集群清理策略为例，在这个集群的所有备份列表，我们会保留集群前 10 天内所有的备份；在 10 天到 90 天的时间段内，我们选择每隔 3 天保留一个全量备份；从 90 天到 180 天，每隔 6 天保留一个全量备份；从 180 天到五年，每隔 15 天保留一次全量备份；对于超过五年的备份，只保留最近的 3 个全量备份。这样的策略设计允许我们的业务在小幅度增加成本的前提下，有能力恢复到较早的数据。

这个保留策略的时间段和时间段内的保留份数都是可以调整的。无论是 10 天到 90 天的区间，还是 90 天到 180 天的区间，亦或是每隔 6 天或每隔 15 天的备份保留间隔，都可以根据实际需要灵活配置。这些配置信息会被存放在数据库中，调整起来比较方便。

3.2.7.2 通用存储

我们设计了一种通用存储方案，这样做的原因是什么呢？公司在最初可能只使用一家云存储服务提供商。但随着业务的发展，可能会因为成本或其他合作条件的考量，需要切换到另一家云存储服务提供商。如果为每一家云存储提供商都单独开发一套接口，这显然是不合理的。

为了避免这种情况，我们设计了一个抽象层，这个抽象层定义了一个通用的接口。无论选择哪家云存储服务提供商，只需要使用它们的 SDK，并将其接口对接到我们的通用接口上。这样，无论业务选择哪家云存储提供商，我们都可以通过简单地修改配置来适配，极大地提高了支持效率和迁移的便利性。

通用存储不仅支持对象存储，还支持非对象存储，比如 HDFS、Ceph 以及我们内部使用的磁盘存储。我们的目标是实现一个接口，使得任何类型的存储都可以无缝地集成到我们的备份系统中，无需对备份系统本身进行任何修改。

举个例子，去哪儿网有一个核心数据库不能将数据传输到外网的对象存储上，即使加密也不行，只能在内网进行异地备份。在内网中，我们使用大容量的磁盘来存储备份。我们在服务器上部署了中转存储，备份数据会以流式传输的方式到达中转存储，然后再由中转存储传输到磁盘上。

同样地，我们也可以使用 HDFS 或其他存储系统，只要它们实现了我们的通用存储接口，就可以无缝地承接数据流，满足我们对业务的存储需求。

3.3 项目成效

1）数据库备份：备份速度提升高至 27 倍，备份速度达 2TB/小时

在老系统中，备份的速度大约是 30MB/s。而在新系统中，如果不进行加密，能够达到 860MB/s 的速度，这是一个超过 27 倍的提升。即使在加密状态下，备份速度也能达到 420MB/s，这比老系统提升了 13 倍。对于数据库加密备份，现在能够以 2TB/小时的速度进行数据库备份，这在业界都是一个相当高的水平。

3.3 图1-数据库备份速度

2）数据库恢复：恢复速度提升 10 倍，恢复速度达 1TB/小时

在老系统中，恢复速度大约是 30MB/s。而在新系统中，对于加密数据的恢复速度可以达到 300MB/s，这基本上是一个 10 倍的提升，使我们能够以 1TB 每小时的速度进行恢复，这在业界也是一个领先的水平。

3.3 图2-数据库恢复速度

3）智能限速：及时响应干扰变化，并确保不会对其他任务产生影响。

3.3 图3-数据库智能限速

智能限速功能也取得了显著的成效。例如，在一次线上测试中，我们将网卡流量的阈值设定为 80MB/s。备份速度从 0 开始逐渐增加，直到达到 80MB/s，并在其上下波动。这符合我们的需求，我们不期望备份开始就以最大速度传输，避免对磁盘产生突增的压力，我们期望备份的速度缓慢上涨。之后我们在测试中故意增加了干扰，比如从一台服务器向另一台服务器传输文件（30MB/s），此时备份速度迅速下降，以适应整体流量不超过 80MB/s 的要求。这表明当前的备份速度其实只有 50MB/s。经过一段时间之后，结束干扰，数据库备份速度开始缓慢上涨，直到服务器整体流量在 80MB/s 左右。动态限速的功能符合我们的预期，我们期望流量是“缓升突降”。这表明我们的智能限速能够及时响应网络条件的变化，确保备份操作不会对服务器的其他任务产生负面影响。

四、个人总结

文章最后，我总结了一些个人的项目经验，供大家参考。