一种多场景通用备份容灾方案

一种多场景通用备份容灾方案_第1张图片

导购链路中,因为业务对SLA的要求和下游无法保持一致,导致很多业务场景需要使用备份容灾。如当业务依赖的下游偶现异常或者超时的情况,在下游无法提供强依赖的数据时,为保证不空窗且当前业务对数据实时性要求不高时,可以使用备份数据来展示。

一种多场景通用备份容灾方案_第2张图片

背景

针对以上情况,需要一份通用的备份容灾方案,能够适用于不同的场景的备份容灾,同时有分页,分桶的能力。即某个场景下可以备份多页数据,每页有多个分桶数据,避免在个性化推荐场景出现大面积异常时,消费者感知的容灾数据一致的问题。

一种多场景通用备份容灾方案_第3张图片

系统架构

  整体设计

系统架构图如下所示,其中业务层分为三部分,备份数据,容灾获取备份数据,清理脏数据。备份分为手动备份和定时备份,清理脏数据分为定时清理和手动清理。底层通用能力包括备份数据的处理,数据的备份方式和相关日志监控。

一种多场景通用备份容灾方案_第4张图片

结构化流程架构图如下:

一种多场景通用备份容灾方案_第5张图片

备份容灾分为3部分,以下分为三部分分别介绍

  备份数据

  • 自动备份

备份分为自动备份和手动备份,当容灾场景较为简单且可枚举,或者在部分推荐场景下,不适用于将某个用户浏览的历史数据作为备份数据,而需要一份通用的数据源作为备份数据,则使用自动备份通过定时任务请求服务数据作为备份数据。当容灾场景较多,无法枚举时,可使用手动备份,即使用用户旧的历史数据作为备份数据即可。当备份数据较大时,可以使用分片,分片的逻辑由业务方实现,在获取备份数据时,如果是分片数据也是由业务方实现组装。

自动备份

时序图如下所示:

一种多场景通用备份容灾方案_第6张图片

业务方需要在handler中实现以下内容:

  1. 获取下游数据的方法

  2. 如果当前备份数据需要分片,实现分片逻辑

定时备份的任务参数需要以下的配置信息

  1. 场景名称

  2. 获取下游备份数据相关的配置信息,如最大分页数等

  3. 分桶需要的参数

  4. 备份数据需要的参数,备份策略有多种,以下是常用的两种

cache备份,需要在配置中加入备份时间。

cdn备份,当服务端接口异常时,前端可以获取cdn数据作为备份数据,需要在配置中加入cdn地址。

  • 手动备份

时序图如下所示:

一种多场景通用备份容灾方案_第7张图片

手动备份时,业务方需要传入以下内容:

  1. 场景名称

  2. 备份策略(cache,cdn或者其他方式)以及备份需要的相关参数

  3. 备份频率(如5%,计算当前是否命中备份概率,防止频繁刷新备份数据)

  4. 需要备份的数据

业务方需要在handler中实现以下内容:(不分片则不需要实现任何handler)

  1. 如果分片,需要实现数据分片逻辑和分片对应的标识key

  备份数据中脏数据清理

数据清理分为自动清理和手动清理,自动清理可用于某些时效性数据,在失效时,设置定时任务进行自动清理。手动清理用于当备份数据出现了部分脏数据时,手动清理这些脏数据以免影响线上容灾效果。

  • 自动清理

时序图如下所示:

一种多场景通用备份容灾方案_第8张图片

自动清理的任务参数需要以下的配置信息:

  1. 自动清理的场景名称列表

  2. 自动清理任务开始时间

  3. 本次清理后是否需要自动生成新的备份数据

  4. 本次清理的唯一标识,以防重复清理

  • 手动清理

时序图如下所示:

一种多场景通用备份容灾方案_第9张图片

脏数据清理提供当备份数据清理,需要由业务方调用接口,接口入参需要有以下内容:

  1. 卡片id,由业务场景定义卡片id,如卖家id等

  2. 清理备份数据类型 ,如对cache/cdn多种备份数据清理哪些备份数据

  3. 场景名称:由此找到业务方自定义的清理类

业务方需要实现handler的逻辑:

  1. 根据入参id,将备份数据的卡片id和入参对比实现过滤

  容灾

时序图如下所示:

一种多场景通用备份容灾方案_第10张图片

以下是自定义不同场景容灾配置:

  1. 是否降级

  2. 场景名称

  3. 分桶相关的配置,如分桶数,分桶策略

  4. 过滤链策略

  5. 容灾使用的备份策略(默认为全部可用备份策略)

其中业务方需要实现handler的逻辑:

  1. 如果需要曝光去重,对传入曝光列表,将备份数据过滤,得到过滤后的数据

  2. 如果需要分片,对分片数据,组装分片逻辑

容灾中使用了如下的分桶策略:

  1. 强不同分桶策略,获取该场景下用户未浏览的分桶id,随机random一个,如果

  2. 没有未浏览,直接返回空

  3. 弱不同分桶策略,获取该场景下用户未浏览的分桶id,随机random一个,如果没有未浏览,则从已浏览的分桶id列表中,random出一个

  4. 相同分桶策略,获取该场景下用户浏览的分桶id,如果有多个,则random一个

  5. 如果业务需要,容灾也提供了备份数据的过滤逻辑:

  6. 时间过滤,即当前备份数据的时间如果是清理脏数据的时间之前,则认为是失效数据,直接过滤。

  7. 曝光过滤,卡片id由业务定义(如卖家id)

强去重策略,将备份数据的每张卡片id和已经曝光id比对,去除已经曝光的

弱去重策略,将备份数据的每张卡片id和已经曝光id比对,去除已经曝光的,如果剩下的结果为空,则放弃去除,直接透出所有的备份数据

一种多场景通用备份容灾方案_第11张图片

小结

本备份容灾有以下优点:

主动备份方式:

大部分备份兜底场景使用了用户的历史数据,本方案除了通过历史数据做兜底数据,也提供了主动备份的方式,可以获取当前实时数据作为兜底数据。

多种定制化的能力:

提供了曝光过滤的能力,当某个场景需要曝光过滤的时候,传入曝光过滤列表,即可筛选出非曝光过滤的备份数据,且提供了多种曝光过滤策略。

提供了分桶能力,可以实现当前场景下用户浏览不同分桶数据,提升用户体验。

提供了分片能力,当某个场景下每一页备份数据较大时,可以分片为多片数据存储,在容灾时,获取备份数据时,会自动组装数据形成原数据。

提供脏数据清理能力:

提供手动清理和自动清理,手动清理可以避免黑名单数据进入备份数据中,自动清理可以定时清理具有时效性的备份数据。

490ac2497e9d87b57d7396fab2a14e7d.png

团队介绍

我们是大淘宝用户平台技术部私域用户运营技术团队,主要用技术和产品能力,构建支撑商家持续经营的基础设施,数据化的为商家带来新的增长。在技术上,我们精益求精,用端到端的技术平台,直面百万级别的QPS,为商家生意的爆发保驾护航;在业务上,我们勇于突破,带领和支撑集团战略级的产品(店铺、订阅、商家会员等),从而推动整个淘宝天猫的增长;在人才上,我们渴望怀揣着有技术梦想的同学加入我们团队,一起为阿里巴巴零售体系的未来布局。感兴趣的小伙伴欢迎发送简历至[email protected]

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法

你可能感兴趣的:(系统架构,数据库,大数据,分布式,运维)