一万亿张的存储架构与4个9可用性的重构丨腾讯技术工程

雅轩格

作者｜xianmau 编辑｜小智 QQ空间（Qzone）是腾讯公司于2005年开发出来的个性化空间，12年过去，目前QQ空间用户数量达到6.233亿。其中，QQ空间背后的平台照片总数接近1万亿。海量数据下，QQ相册是怎么做重构的？ 写在前面 QQ相册作为重量级资深业务，稳定运营、有效容灾，一直是相册团队追求的目标。QQ相册架构一直在演变进化，本文重点介绍相册最新的一次重构细节。重构进行了大规模的存储搬迁、功能模块合并，抽象了上传“两阶段”，并在此之上设计了轻量级的容灾方案。新架构精简了大量模块，优化了上传流程，减轻了运维工作，从实际运营效果看，系统稳定达到4个9的服务质量，并具备跨IDC容灾的能力。 项目背景 QQ相册在之前已经上线了索引异地容灾，当时容灾的设计和实施，受限于人力和设备资源以及保守的升级策略，我们在原有的相册架构和业务流程上进行非常轻量的设计，从过去一年的实际运营情况看，虽然在各种波动和故障中起到了一定的作用，但是由于容灾场景有限，相册体量庞大，存储和索引分布在很多机房，稍有网络波动，业务仍然有较高的感知度。QQ相册接入架平这十年来，业务对相册上传成功率和整体服务质量的要求越来越高，但由于相册逻辑的复杂性，原有架构在容灾、运维和维护（尤其是对新人来说）等方面，并不友好。今年，我们对系统进行了重构！本文总结此次重构的设计和实施，并展示新架构下相册的容灾细节和演习效果，最后总结项目实施过程中的一些思考。 重构目标 从业务角度来说，本项目的实施旨在提高QQ相册上传的成功率，在各种小型网络波动和故障中低感知甚至不感知（上传成功率分钟粒度稳定达到3个9，全天成功率达到4个9），在机房故障甚至大型灾难时，具备快速异地容灾和恢复的能力。对于相册平台来说，主要有以下几个目标：模块合并简化架构优化上传流程优化容灾逻辑 解决方案 整体架构调整 一、原相册架构 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相册上传容灾流程 三、容灾策略 新的容灾流程，容灾策略比较简单，总结起来就是：根据索引preupload的可用性和超时率，决定要不要将上传请求改造成容灾上传请求（容灾请求或容灾重试）根据上传preupload的可用性和超时率，决定要请求就近的上传preupload还是异地的上传preupload（异地请求或异地重试）下面通过不同的视角说明具体的策略实施。业务视角业务根据请求情况进行容灾：proxy不可用，由业务切请求到可用proxyproxy超时，超时率在10%以内可重试一次，超时率在10%以上，视容量切请求到异地proxy（超时率阀值会根据实际运营进行调整）proxy过载，不可重试，视容量切请求到异地proxyproxy返回错误，不建议重试proxy视角1、大型故障导致模块整体不可用，需要直接进行异地请求或索引容灾，请求失败不进行重试。表1：大型故障容灾配置及操作2、普通故障和小波动，直接请求就近preupload，请求失败则根据超时率和错误码采取相应的重试措施。表2：大型故障容灾配置及操作上传preupload视角上传preupload收到proxy的请求，先落地数据，如果是容灾上传，需要生成容灾索引发送到synsrv，普通上传则生成常规索引发送到索引preupload，然后写synsrv备份索引，不进行任何重试。索引preupload视角索引preupload收到上传preupload的请求，写主索引和次要索引，不进行任何重试。synsrv视角收到备份请求，直接回复成功，并且写备份索引；收到容灾请求，先写备份索引，再存储容灾索引，并标记bitmap，所有都成功才返回成功；定期检测是否有容灾索引，有的话，同步回索引点preupload。 四、关于超时时间的设置 重试是容灾的重要手段甚至是必要手段，但是看似简单，实则用好不易，特别地，重试会放大流量，在失败率很高的情况下，过多的重试可能导致机器过载，甚至击垮后端服务，另外，对于多步骤流程的任务来说，在哪些步骤上做重试，以及每一步的超时时间设置，都是挑战。我们考虑了所有模块的过载保护功能，并极简重试机制：在设定的超时率范围内，仅在proxy层面做一次本地重试或异地重试！图7以一条最长的链路说明每个流程的超时时间设定。根据经验，业务对于上传的超时时间为120秒，proxy本地请求一次超时为60秒，本地重试一次超时为60秒，异地请求一次超时为60秒。超时时间可能会在实际运营后进行调整优化。图7：上传接口各流程超时时间配置 重要成果 项目上线已有一段时间，从实际运营效果看，较好的达到设定的目标。1、模块精简。相册重构后，直接下架了三地原图中转rawupload、两地原图落地rawupload、四个园区的转载preupload和回收站preupload等模块，并将原来多园区部署的容灾系统模块统一到深圳园区，业务模块数量从原来的37个减少到18个，极大地简化了维护和运维工作。2、成功率提升。优化了上传流程以及重试策略，重点排查了出现频次top10的错误码，目前上传的成功率从全天平均接近3个9提升到稳定的分钟平均3个9、全天平均4个9的水平。图8为重构优化前的上传成功率统计，图9为重构优化后的上传成功率。图8：重构前上传成功率图9：重构后上传成功率3、容灾能力提升。新的容灾策略基于精心整理的错误码分类，能做到精准的异地容灾，容灾功能上线以来，可以看到一些小波动的故障也能及时触发异地容灾，成功率得到更完备的保障。不过，上线以来还未出现过大型故障，因此我们也进行了现网故障演习，演习结果表明，新的容灾逻辑在应对大型故障也有不错的表现。表3和表4分别为容灾级别为2级和3级配置下的演习数据。表3：容灾Level=2配置下小规模容灾演习成功率表4：容灾Level=3配置下小规模容灾演习成功率 写在最后 相册上传重构项目落地已有一段时间了，从实际运营效果来看，在系统维护、运维、实际上传成功率、业务投诉量等方面，都有不错的优化效果。架构设计中的“分分合合”，是一门学问，相册把数据和索引分开存储，索引又分为主索引和次要索引，轻重分离，提高了存储效率；新架构抽象了上传流程，把数据落地和索引落进行逻辑分离和模块分离，更易于理解和容错设计；而合并了逻辑重合度高的模块，则有利于系统的维护和运维。架构设计上没有永远的相聚也没有永远的分离，只有变化的线上需求，变化的流程，当架构不再适应新的场景时，需要进行重构调整。本文来自“腾讯架构师”公众号投稿，搜索“TencentArchitecture”即可关注。关于腾讯技术方方面面的技术干货，请关注“腾讯技术工程官方号”公众号，第一时间获取腾讯技术资讯。 延展阅读 《存储一万亿张，需要怎样的架构？》 作者介绍 xianmau，2015年加入腾讯TEG架构平台部，一直负责QQ相册平台的维护和建设，主导相册上传架构重构和容灾优化等工作。主要研究方向为口语对话系统、分布式系统架构设计和优化，发表对话系统相关学术论文3篇，系统架构相关专利2篇。 今日荐文 点击下方即可阅读 Web开发这十年 ***【世界欠你的娃娃，在圣诞节送给极客的你】InfoQ旗下经典技术大会门票10+极客时间付费精品专栏200+还有阳光普照的知识大礼包10000+点击下图或阅读原文立刻参与