腾讯技术工程|qq相册后台存储架构重构与跨idc容灾实践

author author     2022-10-13     783

关键词:

作者简介:xianmau,2015 年加入腾讯 TEG 架构平台部,一直负责 QQ 相册平台的维护和建设,主导相册上传架构重构和容灾优化等工作。主要研究方向为口语对话系统、分布式系统架构设计和优化,发表对话系统相关学术论文 3 篇,系统架构相关专利 2 篇。

写在前面

QQ 相册作为重量级资深业务,稳定运营、有效容灾,一直是相册团队追求的目标。QQ 相册架构一直在演变进化,本文重点介绍相册最新的一次重构细节。重构进行了大规模的存储搬迁、功能模块合并,抽象了图片上传“两阶段”,并在此之上设计了轻量级的容灾方案。新架构精简了大量模块,优化了图片上传流程,减轻了运维工作,从实际运营效果看,系统稳定达到 4 个 9 的服务质量,并具备跨 IDC 容灾的能力。


项目背景

QQ 相册在之前已经上线了索引异地容灾,当时容灾的设计和实施,受限于人力和设备资源以及保守的升级策略,我们在原有的相册架构和业务流程上进行非常轻量的设计,从过去一年的实际运营情况看,虽然在各种波动和故障中起到了一定的作用,但是由于容灾场景有限,相册体量庞大,存储和索引分布在很多机房,稍有网络波动,业务仍然有较高的感知度。QQ 相册接入架平这十年来,业务对相册上传成功率和整体服务质量的要求越来越高,但由于相册逻辑的复杂性,原有架构在容灾、运维和维护(尤其是对新人来说)等方面,并不友好。今年,我们对系统进行了重构!本文总结此次重构的设计和实施,并展示新架构下相册的容灾细节和演习效果,最后总结项目实施过程中的一些思考。


重构目标

从业务角度来说,本项目的实施旨在提高 QQ 相册上传的成功率,在各种小型网络波动和故障中低感知甚至不感知(上传成功率分钟粒度稳定达到 3 个 9,全天成功率达到 4 个 9),在机房故障甚至大型灾难时,具备快速异地容灾和恢复的能力。对于相册平台来说,主要有以下几个目标:


  1. 模块合并

  2. 简化架构

  3. 优化上传流程

  4. 优化容灾逻辑


解决方案


整体架构调整

 一、原相册架构

QQ 相册对外提供了丰富的接口,目前存储量超过 300PB,用户索引存储按归属地分布,也达到数百 TB 的量级。当前相册平台虽然较稳定地支撑了如此大量级的业务,但是,系统架构中,模块众多,数据流程复杂,这给开发、运维和维护带来不少麻烦。原相册架构如图 1 所示。

技术分享图片

图 1:原 QQ 相册上传架构


用户使用 app 或 pc 客户端进行 QQ 相册操作,比如上传,修改,删除,拉列表等,这些请求由 preupload 模块完成,而 zz 模块负责图片的旋转和转载,recycle 模块负责相册回收站的操作。这里以最重要的上传操作为例来说明各核心模块的功能以及数据流向,如图 2 所示。相册数据庞大,索引分布在多个园区,单个用户的全部索引信息都落在同一个园区内。通过路由模块可以查询用户索引的归属地。

技术分享图片

图 2:原用户上传流程图


 二、重构架构

以往的架构调整,大都是用“拆”,但是,随着业务数据量的增长,以及业务需求变化的缓和,我们更加关注系统的稳定性和高可用性,于是此次重构,我们采用了“合”的思路,把 zz 和 rececyle 整合进 preupoad。看上去功能耦合了,preupload 变得更加臃肿,但是从 zz 和 recycle 的功能逻辑来看,和 preupload 是一样的或者很相似的,底层也是共用一套存储,将他们独立部署,时间久了,三个模块的代码逻辑差异越来越大,直接导致开发维护和运维的困难。新架构还把一些已经没用的模块去掉,比如 ckv 系统,原图系统等,然后将原图功能完全接入秒传率更高的微云系统,容灾模块也从原来三地部署、两两互备,变成单独园区部署。重构如图 3 所示。

技术分享图片

图 3:新 QQ 相册上传架构


由于相册用户有归属地的问题,导致就近上传请求有超过一半的概率需要进行异地同步索引,在原架构中,上传流程需要判断这一逻辑并分别处理,这使得原本就复杂的上传逻辑变得更加难以理解,而且还给容灾造成极大的困扰。在重构的时候,重点考虑了这一情况,并将上传流程抽象为两个阶段:数据落地和索引落地。这样,上传流程简化为:就近 preupload 接收到上传请求,先将图片数据进行压缩落地,然后将索引信息发送到索引 preupload 去落地索引,如图 4 所示。

技术分享图片

图 4:新用户上传流程图


容灾流程调整


 一、原相册上传容灾

大致的容灾流程如图 5 所示。

技术分享图片

图 5:原 QQ 相册上传容灾流程


 二、优化容灾流程

在新的架构上,把数据落地和索引落地独立看待,容灾流程可以进一步简化。首先,我们利用上传请求协议中的一个预留标志位,巧妙地把普通请求改造成容灾请求,并通过容灾配置项,预设模块的容灾级别。系统根据请求类型(是否容灾请求)、配置项和动态统计信息,实施相应的容灾策略。容灾的数据流如图 6 所示。

技术分享图片

图 6:新 QQ 相册上传容灾流程



 三、容灾策略

新的容灾流程,容灾策略比较简单,总结起来就是:

  1. 根据索引 preupload 的可用性和超时率,决定要不要将上传请求改造成容灾上传请求(容灾请求或容灾重试)

  2. 根据上传 preupload 的可用性和超时率,决定要请求就近的上传 preupload 还是异地的上传 preupload(异地请求或异地重试)

下面通过不同的视角说明具体的策略实施。


业务视角

业务根据请求情况进行容灾:

  1. proxy 不可用,由业务切请求到可用 proxy

  2. proxy 超时,超时率在 10% 以内可重试一次,超时率在 10% 以上,视容量切请求到异地 proxy(超时率阀值会根据实际运营进行调整)

  3. proxy 过载,不可重试,视容量切请求到异地 proxy

  4. proxy 返回错误,不建议重试


proxy 视角

1、大型故障导致模块整体不可用,需要直接进行异地请求或索引容灾,请求失败不进行重试。

技术分享图片

表 1:大型故障容灾配置及操作


2、普通故障和小波动,直接请求就近 preupload,请求失败则根据超时率和错误码采取相应的重试措施。

技术分享图片

表 2:大型故障容灾配置及操作


上传 preupload 视角

上传 preupload 收到 proxy 的请求,先落地图片数据,如果是容灾上传,需要生成容灾索引发送到 synsrv,普通上传则生成常规索引发送到索引 preupload,然后写 synsrv 备份索引,不进行任何重试。


索引 preupload 视角

索引 preupload 收到上传 preupload 的请求,写主索引和次要索引,不进行任何重试。


synsrv 视角

  1. 收到备份请求,直接回复成功,并且写备份索引;

  2. 收到容灾请求,先写备份索引,再存储容灾索引,并标记 bitmap,所有都成功才返回成功;

  3. 定期检测是否有容灾索引,有的话,同步回索引点 preupload。


四、关于超时时间的设置

重试是容灾的重要手段甚至是必要手段,但是看似简单,实则用好不易,特别地,重试会放大流量,在失败率很高的情况下,过多的重试可能导致机器过载,甚至击垮后端服务,另外,对于多步骤流程的任务来说,在哪些步骤上做重试,以及每一步的超时时间设置,都是挑战。


我们考虑了所有模块的过载保护功能,并极简重试机制:在设定的超时率范围内,仅在 proxy 层面做一次本地重试或异地重试!图 7 以一条最长的链路说明每个流程的超时时间设定。根据经验,业务对于上传的超时时间为 120 秒,proxy 本地请求一次超时为 60 秒,本地重试一次超时为 60 秒,异地请求一次超时为 60 秒。超时时间可能会在实际运营后进行调整优化。

技术分享图片

图 7:上传接口各流程超时时间配置


重要成果

项目上线已有一段时间,从实际运营效果看,较好的达到设定的目标。


1、模块精简。相册重构后,直接下架了三地原图中转 rawupload、两地原图落地 rawupload、四个园区的转载 preupload 和回收站 preupload 等模块,并将原来多园区部署的容灾系统模块统一到深圳园区,业务模块数量从原来的 37 个减少到 18 个,极大地简化了维护和运维工作。

2、成功率提升。优化了上传流程以及重试策略,重点排查了出现频次 top 10 的错误码,目前上传的成功率从全天平均接近 3 个 9 提升到稳定的分钟平均 3 个 9、全天平均 4 个 9 的水平。图 8 为重构优化前的上传成功率统计,图 9 为重构优化后的上传成功率。

技术分享图片

图 8:重构前上传成功率


技术分享图片

图 9:重构后上传成功率


3、容灾能力提升。新的容灾策略基于精心整理的错误码分类,能做到精准的异地容灾,容灾功能上线以来,可以看到一些小波动的故障也能及时触发异地容灾,成功率得到更完备的保障。不过,上线以来还未出现过大型故障,因此我们也进行了现网故障演习,演习结果表明,新的容灾逻辑在应对大型故障也有不错的表现。表 3 和表 4 分别为容灾级别为 2 级和 3 级配置下的演习数据。

技术分享图片

表 3:容灾 Level=2 配置下小规模容灾演习成功率


技术分享图片

表 4:容灾 Level=3 配置下小规模容灾演习成功率


写在最后

相册上传重构项目落地已有一段时间了,从实际运营效果来看,在系统维护、运维、实际上传成功率、业务投诉量等方面,都有不错的优化效果。架构设计中的“分分合合”,是一门学问,相册把数据和索引分开存储,索引又分为主索引和次要索引,轻重分离,提高了存储效率;新架构抽象了上传流程,把数据落地和索引落进行逻辑分离和模块分离,更易于理解和容错设计;而合并了逻辑重合度高的模块,则有利于系统的维护和运维。架构设计上没有永远的相聚也没有永远的分离,只有变化的线上需求,变化的流程,当架构不再适应新的场景时,需要进行重构调整。


技术分享图片


大数据架构系列:如何理解湖仓一体?

导语 | 本文推选自腾讯云开发者社区-【技思广益·腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与广泛开发者打造的分享交流窗口。栏目邀约腾讯技术人分享原创的技术积淀,与广泛开发者互启迪共... 查看详情

最佳案例|qq相册云原生容器化之路

关于我们更多关于云原生的案例和知识,可关注同名【腾讯云原生】公众号~福利:①公众号后台回复【手册】,可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~②公众号后台回复【系列】,可获得《15个系列100+... 查看详情

腾讯技术工程|腾讯海外计费系统架构演进

作者简介:abllen,2008年加入腾讯,一直专注于腾讯计费平台建设,主导参与了腾讯充值中心、计费开放平台、统一计费米大师等项目,见证了米大师从0到1,业务营收从PC到移动多终端再到全球化的跨越过程。20+篇支付专利主撰... 查看详情

强烈推荐一本今年八月份的新书《后台开发:核心技术与应用实践》,作者腾讯资深后台开发工程师徐晓鑫

...用实践》,极好的书,评价和口碑超高。  这本书腾讯公司资深研发工程师多年后台开发经验总结,获腾讯、Facebook、微软、阿里、百度多位资深技术专家高度认可。 完整勾勒后台开发技术能力体系,多维度讲解了成... 查看详情

跨园区容灾,升级不停服:高可用负载均衡集群实践

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~本文由腾讯云中间件团队发表于云+技术周刊特别版作者:方坤丁对于云计算行业来说,云服务的可用性和可扩展性是的检测其服务质量的重要标准,也是最受用户关... 查看详情

腾讯技术分享:gif动图技术详解及手机qq动态表情压缩技术实践

本文来自腾讯前端开发工程师“wendygogogo”的技术分享,作者自评:“在Web前端摸爬滚打的码农一枚,对技术充满热情的菜鸟,致力为手Q的建设添砖加瓦。”1、GIF格式的历史GIF(GraphicsInterchangeFormat)原义是“图像互换格式”,是Co... 查看详情

社会化分享在qq互联后台的urlschema应该怎么设置

...o->URLTypes中添加URLSchemes,设置Xcode的urlscheme格式为“QQ”+腾讯QQ互联应用appId转换成十六进制(不足8位前面补0),例如“QQ05FC5B14”。并在QQ互联后台的URLschema中填入此字符串保持一致。额外设置urlschemes的格式为"tencent"+腾... 查看详情

腾讯技术工程|腾讯企业级消息中间件cmq技术解密

作者简介:ziza,2012年加入腾讯,一直专注于腾讯中间件产品的建设,主导参与了腾讯消息中间件CMQ、CKafka、MQforIoT等项目,见证了腾讯云消息服务从0到1的整个过程。目前专注于于分布式服务开发与治理平台TSF的建设。大规模分... 查看详情

idc_isp网络之idc机房内网络架构及配置

...课程面向有CCNP/HCNP基础以上的同学,打算从事IDC网络工程师工作,或即将面试IDC网络工程师岗位,打包成有IDC经验的网络工程师。本博客还在更新中,相关视频已经初步在西瓜视频的视频教程进行简述,欢迎... 查看详情

it:后端进阶技术路线图(初级→中级→高级)后端开发工程师(技术方向分类之后台业务开发/中间件/内核/分布式架构)基础知识简介技术路线/技术趋势指南(如何选择自己的技术方向)之详细攻略

IT:后端进阶技术路线图(初级→中级→高级)、后端开发工程师(技术方向分类之后台业务开发/中间件/内核/分布式架构)基础知识简介、技术路线/技术趋势指南(如何选择自己的技术方向)之详细攻略目录后端进阶技术路线图(初... 查看详情

sreworks前端低代码组件生态演进:monorepo架构重构和远程组件加载实践

...重要一环,提供了一套serverless体验的配置化前端低代码技术方案:低代码、配置化是前端低代码方案的基础特性。frontend工程采用React+antd为主的技术框架,设计了一套组件映射、编排、解析、渲染的工程体系:以antd组件为自由... 查看详情

前端开发工程师怎么分等级知乎

...,叫做“网页制作工程师”或者“Web前端制作工程师”;腾讯的Web前端设置比较特殊,他们的规模较大,不叫UED,而是叫做ISD,他们的分工一般来说也是只负责Web页面的HTML和CSS部分,可能也包含少部分的JavaScript代码,而他们的... 查看详情

技术总监,cto,首席架构师,工程副总在职能上有啥不同

...,但是大公司就可能有很多技术总监,分管不同部门,像腾讯、阿里巴巴等首席架构师---主要是负责架构师团队管理和建设的,以及重大产品的业务和技术架构的审核,若是小公司,就是架构师;工程副总---好像多建房地产及政... 查看详情

[转][知乎]高性能后台架构摘要

...https://zhuanlan.zhihu.com/p/28817489高性能的网络和硬件CDN加速技术。CDN加速将网站的内容缓存在网络边缘(离用户接入网络最近的地方),然后在用户访问网站内容的时候,通过调度系统将用户的请求路由或者引导到离用户接入网络... 查看详情

跨园区容灾,升级不停服——高可用负载均衡集群实践

...升级等需求的解决方案,最能够体现其底层架构的实力。腾讯云基于基础架构的优势,为分期乐、微信红包等平台提供技术支持,可以完美满足如下三点需求:1.高可用能力,容灾能力强,升级不停服2.可扩展性强,功能丰富,... 查看详情

微信架构总监:微信10亿日活场景下,后台系统微服务架构实践!15页ppt全解

点击“技术领导力”关注∆  每天早上8:30推送作者| 许家滔  编辑| 老K作者介绍:许家滔,微信技术架构部后台总监,专家工程师,多年来伴随QQ邮箱和微信后台成长,历经系统从0到10亿级用户的过程。目前... 查看详情

网站运维技术与实践之集群架构规划

集群架构规划和设计只要是涉及到高并发高流量的项目,基本上都需要。本文主要围绕两个方面,一个是IDC的规划和选择,另一个是CDN。一、IDC的规划和选择IDC的选择是网站上线前要做的最重要的事情之一。哪怕发展初期只有一... 查看详情

京东app后台多端融合架构代码重构实战

一简介重构是一个非常常见且古老的课题,涉及重构的文章、书更是不可胜数。但其实做程序做久了就会知道,想把一个复杂的系统做好,尤其是参与人数较多的中大型项目,靠看几本设计模式的书,去试图... 查看详情