在云计算、数字化转型的浪潮下，各组织的数据量规模越来越庞大，这其实给备份产品带来不小的挑战。我们知道，任何备份产品都会有它所能承载的作业上限。当执行中的备份作业超过上限，一般的做法就是让后续的作业进入排队，让作业慢慢被处理。但简单的排队似乎并不能完全解决问题。本文Q先生就和大家唠一唠，备份系统中，备份作业如何才能优雅地排队？

从简单的排队开始

我们以办理银行业务为例。假设银行有 4 个柜台（承载能力为 4 个作业），用户（备份作业）到银行时取个号，等待柜员叫号即可。这种简单的排队系统遵循最朴素的原则：按时间顺序排队，先来的人优先处理。 

备份作业的处理亦是如此，谁先启动备份，谁就得以优先执行。当备份系统负载到达上限之后，后来的作业就只能进入等待。

优先保障核心数据的备份

银行的职员是要下班的，用户备份的窗口也是有限的。往往用户只能在每天的 20:00 到次日的 8:00 进行备份，超过这个“备份时间窗口”，备份的动作就会影响生产业务了。

如果在这样的时间窗口内，无法完成所有的备份作业，那应当如何呢？换句话说，在银行柜员的上班时间内，如果不能处理掉所有用户的业务，那么他们会做些什么？

答案是显而易见的：保障 VIP 客户的业务得到及时处理。

对于备份亦是如此，倘若数据量规模太大、备份系统资源又有限，那么我们要做的事情便是优先保障核心数据的备份。备份系统只需给要备份的对象配置个优先级，并且在备份时，优先处理高优先级对象的备份作业即可。

为不同类型的作业预留资源

如果我们把备份系统所有的资源都留给了备份作业，那么当用户有数据需要紧急恢复时，将无法得到响应。这显然是难以接受的。

银行业务的办理仍然可以给我们启示。我们知道，大家到银行办理的可能是不同的业务，而不同的业务，银行也会有不同的柜台来负责。如下图所示，当业务B存在空闲柜台时，办理对应业务的等待人员就会得到响应。

因此，对于备份系统来说，备份作业和恢复作业不应当使用相同的配额来限制作业数量，分别为备份作业和恢复作业预留独立的资源更为合适。当然，如果我们的备份系统还有其他业务的话，比如：迁移、容灾、演练等等，那么它们也应当有自己的预留资源。

优先保障恢复作业的执行

为不同业务预留资源的方案存在一个比较尴尬的问题，对于备份系统而言，大部分时候，系统都是在执行备份作业的，恢复则是低频动作。如果我们预留资源给恢复，势必会减少日常备份的吞吐量。

因此，这里还有一种解题思路，就是不把恢复作业视为独立的业务类型，而是将其与备份作业一起排队，但享有 VVIP 的优先执行权。

由于恢复作业涉及用户业务恢复，在这个方案里，我们默认恢复作业的优先级比任何备份作业的优先级更高。但实际情况下，用户可能只是做恢复演练，此种情形下的恢复优先级并不那么高，所以备份系统可能在作业类型上还得做细分。当然，不管怎样，若通过此种方式来解决问题，备份系统不得不引入复杂的优先级控制系统。

在此方案中，还有一点需要注意，假设当前作业数量已达上限（所有柜台都在处理业务），若此时发起恢复作业，尽管恢复作业享有 VVIP 的优先级，但仍然需要等待执行中的作业结束。若要能够不排队直接执行，就需要引入 抢占 的逻辑。所谓抢占，便是将正在备份的作业停止，空出资源来执行恢复。

在复杂的制约因素下平衡作业

实际的备份往往比上述场景更加复杂，举几个例子：

• • 备份系统一共可承载 100 个作业，但要备份的虚拟化平台同时只允许执行 20 个虚拟机备份作业

• • 备份系统一共可承载 100 个作业，但部署的备份代理规格不高，同时只能承载 10 个备份作业

• • 备份系统一共可承载 100 个作业，但接入的某个备份存储，同时只能承载 15 个备份作业

• • ......

备份作业往往会涉及生产系统、备份系统、备份代理、备份介质等等。任意一个环节出现瓶颈，都会导致备份系统整体效能的下降。排队系统在此处能做的，便是最大化的利用资源，减少闲置。

我们仍然以银行办理业务为例，假设个人用户和企业用户同时到银行办理业务，银行4个柜台均能办理。但由于企业用户涉及复杂的审核流程，因此银行同时只能为 2 个企业用户办理。如下图所示，假设当前已经有 2 个企业用户和 1 个个人用户正在办理，此时空出 1 个柜台，而排队的下一个为企业用户。此时，空出的柜台并不能为企业用户提供服务，但为保证空出的柜台资源不浪费，柜台可以处理排队中的个人用户业务。

此处以个人用户和企业用户为例仍然属于比较简单的场景，一旦用户类型有了男与女、老与少等更多的区分时，柜台的选举逻辑将变得更加复杂。而复杂正是备份系统需要面临的问题。当作业排队受到很多制约因素影响，有效的平衡资源和作业，最大化利用资源和配额，需要备份系统有灵活的配置，以及实时监控和调配的机制。

复杂的排队系统，需要辅以观测系统

前面我们讲解了一些作业排队的方案和逻辑，如果都做到，那么这个备份系统似乎具备了一个不错的排队系统了，但有一些关键问题我们还需要去解决。

问题1：会不会有数据永远得不到备份？ 这个问题的答案是显而易见的，如果高优先级和低优先级的作业每次都在同一个备份窗口执行时，那么低优先级的作业可能永远不会被备份。就好像，普通人到银行办业务如果一直排不上，那是要出问题的。因此，发现这些没有备份到的数据，会成为用户关注的事情。

问题2：复杂的排队系统下，如何定位瓶颈？ 当排队系统变得复杂，而每次总有数据得不到备份时，我们自然是知道某些地方出现了瓶颈。至于这个瓶颈是什么，是生产系统性能不足？是备份代理部署太少？亦或是备份存储的承载能力不足？这些问题对于用户来讲，是不容易定位的。

要解决上述两个问题，备份系统就少不了观测能力：

• • 统计要备份的数据对象的 RPO，当其长时间得不到备份时（RPO 过长）能够触发告警，以便用户有机会补救。

• • 统计每个作业进入排队的制约因素。有了这样的统计信息，可辅助用户定位问题，消除瓶颈。

结束语

到此，关于备份作业要如何优雅地排队，大家应该有了一些收获了。

但需要注意的是，Q先生并不建议所有的备份产品都去构建这样复杂的系统。对于一个产品来说，“复杂”是一把双刃剑，它带来高级功能的同时，会丧失“简单”。虽然我们在一些企业级的产品里见过这样复杂的排队能力，但同样，我们也见过简单的产品横扫市场。了解自己目标用户的使用习惯和需求，才最重要。

好了，本文就到这里啦~ 咱们下回再聊~

联系Q先生，可以文末私信，或加Q先生好友（微信号：QSirDR）