关于运维:浅谈业务级灾备的架构模式

互联网常见的高可用伎俩。比方服务冗余部署、异步化设计、负载平衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等，明天次要是一起聊下，多机房部署的灾备架构模式，来确保服务的高可用。

::: hljs-center

常见的架构模式

:::

灾备架构比拟常见的几种模式，根本分为同城多核心、跨城多核心、跨国多核心。从字面上看，这几个架构模式如同差不多的，只是间隔上的差别，其余的感觉都差不多的。但，就是简略的间隔上的差别，就会导致在架构上要害的利用场景以及技术实质上有较大的区别。

::: hljs-center

1. 同城多核心架构

:::

同城多核心最典型的就是双核心跟三核心。

同城双核心

简略来说就是在同一个城市部署两个机房。如下图中，IDC- 1 和 IDC-2。两个机房之间通过高速光纤进行连贯。它的一些要害特色是：

（1）雷同城市，间隔在 50km 以上。为什么须要在 50km 以上呢？如果从机房的建设上讲，没有什么不能够，相距 5km 也能够建设。但咱们做双机房，是为了高可用灾备或者备份。一个简略的例子，如果间隔过近，很可能是属于一个片区。如果遇到停电，很可能是一个片区的停电。这样两个机房都不可用了。
（2）光纤互联
（3）机房网络提早 <2ms

同城双核心的架构实质是同城双核心能够当做一个逻辑机房。也就是将同一个集群上的节点，部署在两个物理机房。这样能够应答机房级别的劫难。如下图所示

要留神，同一个集群，部署在两个数据中心，个别要用多条光纤线路，不然容易呈现脑裂。此外还有些特地状况，如下图，能够发现，如果 IDC- 2 挂了，IDC- 1 能失常服务。但如果 IDC- 1 整个挂了，DIC- 2 的 Redis 集群是不可用的。这是因为 sentinel 节点不能实现选举，这里要从架构上进行思考设计。当然也有个方法，就是在 idc- 3 部署一个节点，只部署 sentinel 集群，来防止这个问题。在 IDC- 3 不须要搭建残缺机房, 只须要部署局部决策选举相干的服务，有肯定老本，但整体老本还是比拟低的。

同城三核心

相比同城双核心，三核心就是在同一个城市部署三个机房，相互之间通过高速光纤连贯。三核心，每个核心的定位跟职责都是一样的，比方业务要部署的话，三个都会部署。事实上，很少有公司采纳这种架构。次要的起因是这种同城三核心的老本是比拟高的，然而高可用并没有进步多少，如果产生城市级别的劫难，比方地震、台风等，这三个机房都会受到影响。所以说，想做三机房，个别都是一个同城双核心，而后另外一个机房部署到其余城市。

下图只是示意图，理论的架构要简单得多。

::: hljs-center

2. 跨城多核心架构

:::

跨城多核心也分为跨城双核心和跨城三核心或者四核心等。看下图跨城双核心的架构跟同城双核心的架构是相似的，区别就是机房所在城市不一样。跨城双核心的一些要害特色是：不同城市、光纤互联。

跨城双核心次要的利用场景是 :

• 进行城市级别的灾备
• 用户分区，比方两个城市部署在比拟远的中央，城市 A 在北京，城市 B 在深圳，那能够北方用户接入深圳机房，南方用户接入到北京机房；
• 异地多活

并不是所有的跨城多核心架构都能满足 这几个利用场景，不同的跨城双核心架构有不同的利用的场景。从城市的间隔上，分为近邻城市和远端城市场景。

跨城双核心 - 近邻城市

这个架构的关键点就是抉择两个相近的城市，比方上海杭州、北京天津、广东深圳这种。机房的延时要 <10ms，能够当做同一逻辑机房应用。

利用场景：

• 防止城市级别的劫难，然而无奈防止区域性劫难
• 做异地多活，但不能做用户分区。间隔比拟近，用户分区拜访没有意义

跨城双核心 - 远端城市

远端城市架构模式的要害特色是抉择两个远距离的城市；机房延时 >30ms，不能当作同一逻辑机房；

利用场景

• 防止城市级别和区域性级别的劫难
• 适应异地多活架构
• 能够做分区架构

跨城多核心

跨城多核心的个别利用场景，就是用户分区、就近接入、异地多活。

能够联合 OceanBase 官网举荐架构来了解。如下图，采纳两近（提早 10ms）一远（提早 30~50ms）的部署模式，能够应答城市级别故障，可靠性是最高的；不过老本也是最高的。为什么要 2 近 1 远？其实这跟 oceanBase 自身的技术实现有关系，底层为了保障一致性，是通过 proxy 协定一直的进行通信、投票来保障的，必须要保障服务之间通信的性能。一远是为了保障应答城市级别的故障。

::: hljs-center

3. 跨国数据中心架构

:::

跨国数据中心

跨国数据中心的根本特点：
（1）寰球部署
（2）合规和监管，不同的地区的数据法规不一样，比方用户的隐衷信息之类的
（3）区域用户分区
（4）不能做异地多活。一个起因是时间延迟问题，另外还是在于合规跟监管，不同地区的合规跟监管数据隐衷爱护的不一样，没方法做异地多活。

能够看下 Google 和 Facebook 的跨国数据中心，下面的图是 Google 的下图是 Facebook 的

跨国数据中心。次要部署在北美、欧洲、亚洲区。

::: hljs-center

4. 五种架构比照

:::

次要从利用场景维度看下几种架构的区别

像常见的冷备、双机热备、同城双活、异地双活、异地多活根本都是汇合本人的业务场景及倒退阶段对以上几种架构模式的利用。咱们上面次要说下异地多活的集中模式。

::: hljs-center

异地多活的三种模式

:::

异地多活的落地能够概括为有三种大的模式，业务定制型异地多活、业务通用型异地多活、业务存储型异地多活。

::: hljs-center

1. 业务定制型异地多活

:::

简略来说，业务定制型异地多活，就是依照业务的优先级进行排序，优先保障外围业务异地多活。而后基于外围业务的流程和数据，设计定制化的异地多活架构。然而 A 业务做的计划，并不能间接用到 B 业务上。比如说电商业务做的双活，不能用到社交的业务上，架构的计划并不通用。
如下图中的示意图：

• A 业务通过数据库 + 音讯队列同步的形式实现，
• B 业务通过数据库 + 算法的形式实现异地多活。
• 两种业务的实现形式是依据本身的业务场景来决定的。

这种模式的长处就是：对基础设施没有强要求，例如机房部署、存储系统、时延等，个别是部署在远距离的两个城市，能够反对区域级别故障解决。
毛病也比拟显著，不通用，每个业务都须要独自来做异地多活，业务须要革新。难扩大，外围业务如果有重大变动，异地多活计划须要从新设计。

::: hljs-center

2. 业务通用型异地多活

:::

这种形式个别是通过配套服务来反对异地多活。绝对于业务定制型架构，个别无需依照优先级排序来筛选某些业务实现异地多活，只须要判断业务是否能异地多活，当然，业务理论落地的时候可能会有阶段或者灰度过程，并不是一步到位。这种架构的优缺点：

• 长处

  a. 对硬件基础设施没有强要求，例如机房部署、存储系统、时延等，个别部署在远距离的两个城市，能够反对区域级别的故障解决。

  b. 业务根本不做革新或做较小的革新，只须要判断业务是否反对 BASE, 反对就能够做异地多活，不反对就单点部署。这个也是要依赖业务零碎后期的设计。

• 毛病

  a. 配套服务简单，包含流量调度、容灾切换、建站平台、配置管理等

  b. 存在全局单点业务。例如库存、卖家等相干业务

机房间隔较远的时候，RTO 比拟大，可能达到分钟级。异地多活基础理论是 Base，肯定工夫内达到最终统一，这个工夫范畴可能会较长，有可能会达到分钟级。

示意图

「案例 」淘宝的单元化架构
把业务分成很多个单元，每个业务绝大部分申请都能够在本单元内实现。不同的用户划分到不同的单元。除了单元还有个中心点。比方库存信息，全量的商品及卖家数据。再把数据复制到各个单元去。

示意图

【单元】单元（即单元化应用服务产品层的部署单元），是指一个能实现所有业务操作的自蕴含汇合，在这个汇合中蕴含了所有业务所需的所有服务，以及调配给这个单元的数据。单元化架构就是将单元作为部署的根本单位，在全站所有机房中部署多个单元，每个机房内单元数目不固定，任一单元均部署零碎所需的全副利用，数据则是全量数据依照某种维度划分后的一部分。

::: hljs-center

3. 存储通用型异地多活

:::
基于业务通用性架构去做，有的业务不能满足 base 实践，就不能实现异地多活。那有没有一种办法，与业务不强相干，实现多活的架构设计呢？答案必定是有的，从存储系统来实现，采纳自身曾经反对一致性的存储系统，实现存储通用型异地多活。

存储通用型异地多活架构计划的长处就是人造反对异地多活，业务除了切换存储系统外，其余根本不做革新。也不须要剖析本人的业务场景、优先级。

毛病就是

（1）须要分布式一致性的存储系统反对。目前这样的存储系统可选不多，例如 zookeeper、etcd、OceanBase。实际上 zookeeper、etcd 不适宜存储大量数据的。

（2）对机房部署有强要求，如果实现异地多活，只能采纳近邻部署。分布式一致性框架，是须要通过协定通信的，这个对性能跟速度要求是有要求的，如果是分布式存储系统之间的节点，通信性能很差的话，那么会导致这个零碎的读写性能会很差，就满足不了业务需要了。

「案例 」蚂蚁的 OceanBase
目前为止，OceanBase 是比拟典型的一个分布式存储，而且是真正落地的一个分布式一致性存储系统。简略了解 OceanBase 就是一个基于 Paxos 算法来实现的分布式一致性存储系统。【参考官网介绍】

如上图，简略了解：

（1）Zone 是一个机房内的一组服务器，蕴含多台 OceanBase 数据库服务器(OBServer)，个别会把数据的多个正本散布在不同的 Zone 上，能够实现单个 Zone 故障不影响数据库 服务。

（2）每台 OBServer 蕴含 SQL 引擎、事务引擎和存储引擎，并服务多个数据分区，其中，每 个 Zone 有一台 OBServer 会同时使能总控服务(RootService)，用于执行集群治理、服 务器治理、主动负载平衡等操作。

（3）OBServer 上会运行 SQL 引擎、事务引擎和存储引擎，用户的 SQL 查问通过 SQL 引擎 解析优化后转化为事务引擎和存储引擎的外部调用。

（4）OceanBase 数据库还会执行强统一的分布式事务，从而在分布式集群上实现数据库事务 ACID。(参考链接 :https://zhuanlan.zhihu.com/p/41139701）

参考下图了解，部署上个别要求 2 近 1 远，间隔相近的两个城市，每个城市的机房都要部署 2 个 Zone，较远的城市部署一个 Zone.

「案例 」蚂蚁的 LDC 架构
联合淘宝单元化的架构 +OceanBase

示意图

如上图，简略了解：

RZone(Region Zone): 部署按用户维度拆分 的要害业务零碎。外围业务和数据单元化拆分，每个单元内尽量调用闭环，领有本人的数据，能实现所有业务。一个可用区能够有多个 RZone。

GZone(Global Zone): 部署未按用户维度拆分的零碎，全局只有一份，被 RZone 依赖，提供不可拆分的数据和 服务，如配置型的业务。数据库能够和 RZone 共享，多租户隔离，全局只有一组，能够配置流量权重。

CZone(City Zone): 部署未按用户维度拆分的零碎，被 RZone 高频拜访，解决跨域通信延时问 题。为了解决异地提早问题而特地设计，适宜读多写少且不可拆分的业务。以城市为单位部署的单元，个别每个城市一套利用和数据，是 GZone 的只读正本。

能够自行看下支付宝的案例介绍。（支付宝案例链接：https://www.sohu.com/a/406634738_99940985）

::: hljs-center

4. 三种模式比照

:::

从利用场景和实现老本上看下三种模式各有优缺点

::: hljs-center

异地多活架构关键技术（通用型）

:::

大厂个别罕用的计划是通用型的技术计划。咱们重点说下业务通用性的架构上的一些要害实现。

::: hljs-center

1. 流量调度

:::

次要是负责将用户的申请流量调配到对应的单元, 例如蚂蚁的 Spanner。Spanner 是蚂蚁金服的七层网络代理，承载了蚂蚁金服所有的业务流量，包含支付宝 App、Web、商户等的终端拜访。

如下图，用户通过蚂蚁金服的网络入口进来，通过多协定接入，到 LVS 和 Spanner，Spanner 作为对立七层网关把申请分发给前面的利用。在 Spanner 上有很多业务逻辑、协定反对，比方 TLS 1.3、QUIC、HTTP 以及蚂蚁自研的协定等。蚂蚁的所有业务，包含支付宝钱包、其余页面都是通过这个入口进来。

下图是 spanner 在三地五核心架构中的流量调度的场景，也能够发现，通过流量调度可实现：

• 机房内 zone 随机路由
• Cookie zone 转发
• 容灾
• 弹性调度
• 压测
• 灰度、蓝绿公布

  ::: hljs-center

2. LDC 路由

:::
异地多活架构下的路由核心，个别分三层。第一层是判断决定拜访哪个机房或单元。第二层是在服务间调用的时候，来判断申请应该到哪个单元。第三层是到拜访数据层，最初一层的兜底，决定拜访到哪个 DB.

联合蚂蚁的架构，看下路由状况

【入口流量路由】

    箭头 1: 对于应该在本 IDC 解决的申请，就间接映射到对应的 RZ 即可;

    箭头 2: 不在本 IDC 解决的申请，Spanner 能够转发至其余 IDC 的 Spanner。

【服务路由】

    RPC 调用、MQ 的一些场景，有些场景来说，A 用户的一个申请可能关联了对 B 用户数据的拜访，比方 A 转账给 B，A 扣 完钱后要调用账务零碎去减少 B 的余额。这时候就波及到:

    箭头 3: 跳转到其余 IDC 的 RZone;

    箭头 4: 跳转到本 IDC 的其余 RZone。

【数据路由】

RZ 拜访哪个数据库，是能够配置的，对应图中箭头 5。

3. DRC

(Data Replication Center)：数据复制核心，次要是反对异构数据库实时同步，数据记录变更订阅服务。为业务跨域实时同步、实时增量散发、异地双活、数据双向同步、数据巡检、redis invaild 等场景提供反对。能够参考 otter 的架构设计。

单机房同步

如上图所示：

数据 on-Fly，尽可能不落地，更快地进行数据同步。(开启 node loadBalancer 算法，如果 Node 节点 S +ETL 落在不同的 Node 上，数据会有个网络传输过程)。Node 节点能够有 failover / loadBalancer。

异地多活同步

如上图所示：

数据波及网络传输，S/E/T/ L 几个阶段会扩散在 2 个或者更多 Node 节点上，多个 Node 之间通过 zookeeper 进行协同工作 (个别是 Select 和 Extract 在一个机房的 Node，Transform/Load 落在另一个机房的 Node)。

Node 节点能够有 failover / loadBalancer. (每个机房的 Node 节点，都能够是集群，一台或者多台机器)。

::: hljs-center

4. DAL

:::
DAL 是 proxy 型的数据库中间件，反对 mysql 协定。在多活我的项目中，DAL 义不容辞表演起爱护数据正确性最初一道防线的角色。

对于个别一致性要求很高的利用，个别提供了一种强统一的计划，比方饿了么的架构中的 Global Zone，Globa Zone 是一种跨机房的读写拆散机制，所有的写操作被定向到一个 Master 机房进行，以保障一致性，读操作能够在每个机房的 Slave 库执行，也能够 bind 到 Master 机房进行，这所有都基于数据库拜访层 (DAL) 实现，业务根本无感知。

::: hljs-center

5. 配置核心

:::
负责 Zone 的配置和容灾切换，例如 RZone 的业务范围，Zone 拜访哪些数据库等。

::: hljs-center

6. 公布平台

:::
服务多机房的公布。基于流量调度，实现 Zone 的蓝绿公布、灰度公布等。

::: hljs-center

7. 建站平台

:::
疾速新建一个残缺的单元，蕴含机器搭建、基础设施搭建，服务部署等，目前根本都是基于容器技术实现的。

::: hljs-center

异地多活架构设计的办法

:::

在理论的落地过程中，还是有一些通用的架构设计办法来做参考。

::: hljs-center

1. 异地多活 – 3 大准则

:::
完满是优良的敌人，不能过于谋求完满。在落地异地多活的时候，个别要恪守 3 个准则

（1）只保障外围业务。不同业务的数据个性不同，无奈全副做到异地多活

（2）原则上只能做到最终一致性。复制必定有工夫窗口，摈弃实时一致性的想法。能够理解下【PACELC 实践】

（3）只能保障绝大部分用户。不能为了 0.01% 的用户，影响到 99.99% 的用户。

::: hljs-center

2. 异地多活 – 4 个步骤

:::
（1）业务定级

将业务依照某个维度进行优先级排序，无限保障 Top3 业务异地多活。个别定级的方向，能够从访问量、外围场景、支出起源看。

访问量：登录 > 注册 > 批改明码
外围场景：交易 > 社区
支出起源：订单 > 搜寻 > 编辑

（2）数据分类

剖析 TOP3 中的每个业务的要害数据特点，将数据分类。

• 数据批改量
  数据被批改的数量和频率，包含新增、删除、批改。
• 一致性
  数据的一致性要求，例如：强一致性（余额、库存）、最终一致性（动静、趣味）。
• 唯一性
  数据的唯一性要求，例如：全局惟一（用户 ID），可反复（昵称）
• 可失落性

数据是否可失落，例如不可失落（账户余额、订单）、可失落（tocken、session）

• 可恢复性

数据是否可复原，例如：用户复原，零碎提供复原（密码找回）、外部复原（例如编辑和经营重发）

（3）数据同步

针对不同的数据分类设计不同的数据同步形式。

（4）异样解决

针对极其异样的状况，思考如何解决，能够是技术手段，也能够是非技术手段。

• 业务兼容

体验不好优于无奈体验。比方数据短时间不统一，数据临时无奈获取。

• 预先弥补

大量用户损失，能够用钱解决。适当弥补优惠券。

• 人工修复
  人工订正数据，达到最终统一。

::: hljs-center

异地双活实际

:::
::: hljs-center

1. 概述

:::
下图是以后得物双活架构的业务示意图，蕴含了路由核心、DRC、DAL、配置核心等基础设施。

如图所示，用户在 app 发动申请后，客户端会先依据缓存的信息，判断该用户应该拜访到哪台 SLB，而后 SLB 将申请转发到 DLB，DLB 会依据最新的路由规定，判断该用户是否属于本单元，如果是持续在本单元流转，如果不是，将申请转发到相应单元。如图中绿色申请所示，该用户理论规定应该路由到 B 机房，理论申请到 A 机房后，在 DLB 层也会将申请转发到 B 机房。应用服务注册的时候会标记本人的地址、服务类型。以便通过 RPC 服务间调用的时候进行路由。

在异地双活落地的过程中，重点说下需关注的几个点。

::: hljs-center

2. 重点模块

:::
### 数据拆分

从业务角度剖析，最次要的是数据拆分。每个单元有局部用户的数据，用户尽可能地在本单元实现所有的行为操作。对于非用户维度的数据，部署在核心单元（机房），向单元机房做单向同步。为了灾备，用户维度的数据，单元机房和核心机房之间会双向同步。

数据架构示意图

数据同步

依照业务的拆分规定，单元模式的数据，不同的用户会在不同的单元进行写入。单元和核心之间会双向同步。另外一种是核心模式的数据，这部分数据在核心写，全量同步到单元。可在单元进行拜访。如果以后库既有单元模式的物理表又有核心模式的物理表，不倡议混合在一起，最好进行拆分。

单元化模式：两边都会写入，双向进行同步，保障两边都有全量数据。保障在流量切流后，用户拜访数据不受影响。

::: hljs-center

单向复制模式：只在核心写入，向单元全量同步，属于单元只读。

:::

还有一种是仅在核心部署的，比方库存数据，有强一致性要求，只在核心部署。数据的同步是通过 DRC 来实现的。

### RPC 服务框架

次要是通过 rpc 框架，让开发者不须要关怀调用服务的细节。provider 将本人的服务，注册到注册核心，consumer 从注册核心拉取服务，并进行生产调用。在 rpc 框架外部，缓存了路由策略。能够间接在 consumer 获取服务时，依据规定进行筛选。让服务间的调用较简略。而且也进步了路由调度的灵活性。比方机房就近调用，单元化路由调用等。这也是上述 LDC 路由中的第二层路由。

个别的单元化规定：

（1）哪些用户属于哪个单元（2）哪些利用属于单元

但理论利用中，还有比较复杂的场景，从利用场景上，目前次要是分为三种：一般服务，单元服务，核心服务。

【一般模式】的服务就是没有做单元化革新的服务，没有单元的概念。服务间调用是就近调用，也就是本单元优先调用，如果本单元没有，会去核心调用。核心对一般服务的调用，也是间接调用核心的一般服务。

【单元模式】的服务是单元化路由服务，会依据路由 key(用户 ID)，将申请进行路由到正确的单元。

【核心模式】的服务，只管在核心和单元的注册核心都会注册，但申请最终只会路由到核心去。

缓存失败

做了双活之后，缓存生效的逻辑也会有肯定变动。大部分利用，原缓存生效逻辑是：利用发动数据更新操作，先更新 DB 的数据，再进行缓存生效的解决，下次有申请的时候，数据从 DB 加载到缓存。

但做了双活之后，核心的数据产生变更，单元的缓存也要做生效解决。但单元的缓存生效不能间接依赖核心 DB 的变更音讯。如果间接依赖核心 DB 的变更音讯，单元的缓存生效有可能在单元 DB 变更之前生效，此时用户来拜访，可能把旧数据写入缓存，导致数据不统一。

所以目前的解决方案是，通过 DRC，将核心的 DB 数据同步到单元，单元 DB 变更后，会通过 DRC 把 binlog 发送到 MQ，利用再去操作缓存生效或更新。

MQ 音讯

MQ 中间件也是须要做革新的，要保障音讯可能落到正确的单元，并在正确的单元生产。

做双活前原有的的逻辑，大部分是承受音讯后，对数据进行插入或更新操作。如果做了单元革新的库，局部数据曾经依据相应策略划到对应单元写入，这时音讯却在核心进行生产，这会导致两边双写，呈现脏数据。这就须要 MQ 也有有路由的能力，让音讯路由到正确的单元，不仅仅是依赖 RPC 框架或 DAL 层的路由限度。

目前的计划，音讯会双向复制。依据生产方配置的订阅形式，进行订阅生产。

• 核心订阅，只在核心生产
• 一般订阅，就近生产本单元的音讯。
• 单元订阅，各单元生产各单元的音讯。DMQ 会依据路由规定路由到所属单元生产
• 全单元订阅，发到所有单元，所有单元都会生产一次

::: hljs-center

3. 容灾能力 & 策略

:::

（1）切流步骤

• 禁写切流局部用户的申请。在流量入口、RPC 框架、DAL 层都会进行拦挡，将申请抛弃，并抛异样。
• DRC 依照工夫节点，确认同步是否实现。
• 数据同步实现后，依照最新的路由规定开始进行路由。

（2）容灾场景

单元机房呈现故障，能够将流量切到核心新房

核心机房故障，以后的计划不能解决。能够在后续做到核心故障切换到核心备份环境，或者说，核心机房做逻辑机房，加强核心机房的抗灾能力。如下示意图

::: hljs-center

【附录】

:::
::: hljs-center

常见的几个外围指标含意

:::
【RTO】（Recovery Time Objective），即复原工夫指标。次要指的是所能容忍的业务进行服务的最长工夫，也就是从劫难产生到业务零碎复原服务性能所须要的最短时间周期。RTO 形容了复原过程须要破费的工夫。例如：假如在工夫点 t1 启动复原过程并且在工夫点 t2 实现复原，那么 RTO 就等于 t2-t1。RTO 值越小，代表容灾零碎的数据恢复能力越强。RTO= 0 就意味着在任何状况下都不容许指标业务有任何经营进展。

【RPO】（Recovery Point Object)复原点指标，指一个过来的工夫点，当劫难或紧急事件产生时，数据能够复原到的工夫点，是业务零碎所能容忍的数据失落量。例如每天 00：00 进行数据备份，那么如果明天产生了宕机事件，数据能够复原到的工夫点（RPO）就是明天的 00：00，如果凌晨 3 点产生劫难或宕机事件，损失的数据就是三个小时，如果 23：59 产生劫难，那么损失的数据就是约 24 小时，所以该用户的 RPO 就是 24 小时，即用户最大的数据损失量是 24 小时。所以 RPO 指的是用户容许损失的最大数据量。这和数据备份的频率无关，为了改良 RPO，必然要减少数据备份的频率才行。RPO 指标次要反映了业务连续性管理体系下备用数据的有效性，即 RPO 取值越小，示意系统对数据完整性的保障能力越强。

能够通过下图来比照 RTO 和 RPO。

从图中不难看出，RPO 指标来自于故障产生前，而 RTO 指标来自故障产生后，两者的数值越小，就能无效缩短业务失常到业务过渡期的工夫距离，繁多地晋升 RTO 或 RPO 指标也能够缩减业务故障到过渡期的工夫，具体从哪个指标上来改善，就要联合的理论状况剖析，晋升那个指标代价最小，成果更显著。

【WRT】(Work Recovery Time)，工作复原工夫，指“零碎恢复正常后，复原业务所需的工夫”，因为要进行各种业务查看、校验、修复。

【MTD】(Maximum Tolerable Downtime)，最大可容忍宕机工夫，等于 RTO + WRT。

参考资料：
李运华《从 0 开始学架构》《架构实战专栏》

文 / 胡强忠

​线下流动举荐 ：得物技术沙龙「企业合作效率演进之路」（总第 19 期）
工夫 ：2023 年 7 月 16 日 14:00 ～ 2023 年 7 月 16 日 18:00
地点：（上海杨浦）黄兴路 221 号互联宝地 C 栋 5 楼 (宁国路地铁站 1 号口出)

流动亮点：在当今竞争日益强烈的商业环境中，企业合作效率成为企业团队胜利的要害。越来越多的企业意识到，通过信息化建设和工具化的反对，能够大幅晋升合作效率，并在行业中获得冲破。本次沙龙将涵盖多个主题，这些主题将为与会者提供丰盛的思考和教训，助力企业合作效率的晋升。通过得物技术沙龙这个交流平台，您将有机会与其余企业的代表一起学习、借鉴彼此的教训和做法。独特探讨企业外部合作效率的最佳实际，驱动企业长期生存和倒退。退出得物技术沙龙，与行业先驱者们一起开启合作效率的新篇章！让咱们独特为合作效率的冲破而致力！

点击报名 ：得物技术沙龙「企业合作效率演进之路」（总第 19 期）
本文属得物技术原创，来源于：得物技术官网
未经得物技术许可严禁转载，否则依法追究法律责任！
作者：得物技术链接：juejin.cn/post/724957…