本文从设计和服务可用性两个方面详细分析了微博短视频高可用高并发架构设计中存在的问题和解决方案。今天要跟大家分享的是微博短视频业务的高并发架构。具体内容分为以下三个方面：团队介绍微博视频业务场景“微博故事”业务场景架构设计团队介绍我们隶属于微博研发部视频平台研发部技术团队。平台研发是微博的核心部门之一。包括知名微博视频在内的微博所有核心业务的基础平台架构和用户关系体系，都依赖于微博平台研发部的技术支持。我们团队主要负责视频相关的上层业务，即视频微博、“微博故事”、短视频和直播。直播包括定期直播、直播答疑等新方式。同时，我们还负责视频平台的底层建设，包括文件平台、转码平台、配置调度中心和媒体库。我们致力于用技术帮助微博从容应对每天的视频增量和背后多元业务的各种定制化需求。微博视频业务场景我们的业务场景主要是应对热门事件的流量激增，比如明星绯闻、爆炸性新闻等事件势必会在短时间内造成流量的快速增长。流量暴涨时，如何从架构上保证整体平台的稳定性？如果单纯通过调整服务器规模来解决，服务器冗余过多，在流量小的时候会造成成本浪费，而服务器太少，在流量猛增的时候又会使得平台无法服务。在崩溃的边缘。更特别的是，我们面临的问题与“双十一”等一定时间内可预测的流量高并发有着根本的区别。我们面临的流量激增是不可预测的。因此，采用何种技术手段妥善解决上述问题，将是接下来讨论的重点。以上是基于微博过去公开数据的量级，并非近期内部数据。微博视频是一个多业务接入的综合平台。微博上可以看到市面上的各种玩法。结果，我们即将面临的不是某个垂直业务领域的攻击，而是在庞大体量下构建的综合攻击，这使得现有的通用技术框架无法妥善解决我们面临的问题。问题。由于部分开源方案无法顺利通过技术压力测试，我们只能在开源方案的基础上进行自研和优化，以获得符合微博应用场景需求的技术方案。微博的短视频业务被称为“微博故事”。上图为“微博故事”的展示形式。这是设置在微博首页一级入口的一个模块，主要展示用户在15秒内关注的人上传的短视频。我们要强调它的“即时互动”属性，视频只有24小时有效。不同用户的视频按照时间轴排序在最上方，多个视频可以依次观看、评论、点赞等。《微博故事》业务场景架构设计微服务架构上图展示了该业务的微服务架构：在接口层，我们混合了WebAPI和内部RPC请求。这里我们并没有集成具有实际意义的门面层，而是下一个服务层集成了很多微服务，每个微服务专注于一个垂直的功能，可以对外提供接口，门面层这里的主要功能是聚合一些微服务也提供全面的与外界的接口。此外，还有一些依赖的服务，如用户注意力、RPC服务等，也依赖于其他部门；最先进的存储层是一个集成Cache和db的标准解决方案。技术挑战曾经有人问：微博短视频业务的高并发有多高？假设我关注了500个好友，如果有好友发视频，“微博故事”头像列表会显示一个色圈。提示我观看它。如果我想知道我关注的所有500个人发送的视频内容，假设首页每秒刷新10万次，那么每秒需要5000万个QPS。此外，我们还需要判断视频是否过期，视频的发送顺序等，实际资源层读取量会远高于5000万。方案对比我们在构建方案时思考：可以借鉴微博之前的feed方案，不会进行无意义的重复工作和思考。尽管短视频和Feed都具有刷新首页和聚合??关注者发布消息的特点，但短视频以用户列表的形式强调进度更新和即时交互，而以内容列表的形式则强调无阅读状态和**已存微博有着本质的区别。一般的feed应用场景可以采用以下两种模型：Feedpush模型Feedpull模型①Feedpush模型feed推送模型是指将用户上传发布的内容推送给每一个粉丝，有很大的弊端。由于用户尚未达到一定规模，早期的微博以动态推送模式为主。现在大V用户的粉丝数量普遍都是同性的。如果还是用feed推送的模式，那就意味着千万级的内容推送。当千万级推送的一致性难以保证时，势必会给Server带来巨大的压力。微博的业务强调时效性强下的内容一致性。我们需要确保热点事件被即时且持续地推送。除了从技术层面难以保证个别内容推送的时效性和一致性外，由于用户在线状态不一致，为线下用户推送时效性强的内容无疑是对服务器等资源的巨大浪费。上面的麻烦我们要换个思路。②Feed拉动模式Feed拉动模式：拉动你关注的人，实时查询状态和内容。考虑到微博庞大的用户量、数据写入开销以及保证一致性，我们决定选择Feedpull模型。如何通过feedpull模型来应对如此大规模的QPS？首先，我们采用分布式缓存架构，在缓存层集成数据分片，通过哈希算法对缓存进行合理分片，然后对缓存进行分片存储。挑选。分布式缓存架构其次，我们采用了独特的多级缓存方案，即L1、Master、Slave三级缓存方案。L1是极热极小的缓存，我们称之为“极热缓存”，其特点是可以轻松横向扩展。假设L1只有200MB缓存，我们通过热度分析，使用LRU算法将访问量最大的数据存放在L1中；后续的Master和Slave缓存空间分别为4GB和6GB，比L1大了很多倍。由于微博的流量相对集中在几个明星或某条热点新闻上，小容量的L1可以快速扩容；当热点事件发生时，可以利用云的弹性自动扩容来分担热点事件短期激增的流量压力。由于L1在自动扩容时只在每个缓存中占用很小的空间，所以扩容速度会非常快。这种手动或自动的瞬时弹性扩容，可以保证服务器能够稳定承受热点事件背后的数据激增。第二层的Master和Slave拥有比L1大很多倍的缓存空间，主要用于防止数据冷磨损。L1虽然主要负责热点数据，但当流量短时间不热点，但某段时间突然热度上升时，无法保证服务器的稳定性。HA多机房部署，Master和Slave作为L1逻辑分组，有效防止数据过冷。这里我们采用HA多??机房部署。例如图中的两个IDC，我们称左侧为IDC-A，右侧为IDC-B。缓存层的Master和Slave是主从同步关系，双机房的缓存相互主从同步。这里的“主从互同步”指的是IDC-A的MC和IDC-B的MC之间的双向同步。由于部署两个机房时需要平衡两个机房的流量负载，所以需要在缓存层使用LRU算法进行热分析。如果我们把流量分成两部分分别传送到两个机房，每个机房的IRU算法得到的热度信息都会有一定程度的失真。如果我们在缓存层做相互同步，每个机房的MC都是全热算法，那么两个机房的L1基本可以实现同步计算。获得的热量信息必须准确。只有保证热度信息的准确性，才能从容应对流量激增和整个系统的高可用。这里需要强调的是，我们实际上是使用MC而不是Redis来进行模型选择的。MC对纯粹简单的数据Key和Value的抵抗力要比Redis强很多；MC将Key和Value以预分配内存的形式放置，即将内存分成几组相同的数据区，实际上是几个数组。这种特殊的结构使其在数据位置数组寻址和读写时速度非常快；这种结构的缺点是：一旦缓存的数据发生变化，即使内存空闲也无法存储数据的现象。由于这个问题的存在，MC不适合存储变化大、值跨度大、业务变化大的数据。Redis作为单线程方案，一致性较好，但在读取大规模简单Key和Value时比MC慢很多。除了上述解决方案，我们还采用了弹性伸缩。在实际应用中，基于成本的考虑，我们无法部署大量的服务器，所以我们采用了自研的DCP弹性伸缩平台。首先，我们自己的机房有一些共享的机器资源，可以在特殊情况下动态弹性扩展，以应对增加的流量压力。当然，这些机器的性能是有限的。当数据量超过一定阈值时，我们会接入阿里云，利用我们与阿里云的混合云DCP搭建一层弹性软平台，自动扩容，承受流量压力。除了弹性扩容，我们还采用了定时扩容的逻辑，每天晚上高峰期进行扩容和缩容，保证整体服务的稳定性。之所以这样做，主要是为了在保证用户体验的同时，尽可能的节省成本。需要强调的是，扩展对速度有严格的要求。只有扩容速度越快，在流量高峰到来时能够容忍的数据量越大，才能保证整体服务的高可用。因此，我们也在努力优化扩展速度。我们的DCP平台还有晚高峰扩缩容和突发流量临时扩缩容。通过流量监控等自动化容量评估判断服务器负载，通过自动化任务调度妥善解决突发流量对服务器的影响。.微服务熔断机制当然，为了保证服务器整体的健康稳定，我们也集成了微服务熔断机制。其原理类似于家用电表中的保险丝，在过载情况下能迅速自动熔断。系统会定期进行自我评估，确定每项服务的最大负载。假设熔断值设置为3000QPS，那么当QPS超过3000、超时或异常时，服务会被快速熔断关闭，从而保证其他资源的安全稳定。通过这种框架级的、细粒度的自动降级机制，可以有效提升系统故障隔离能力，避免雪崩式的连锁宕机事件的发生。与断路器同时，自动扩容也同步运行。熔断后，系统会持续更新服务流量负载。一旦扩容完成或者服务可以继续承载流量，就可以复工了。这种断路器机制也为服务器扩容争取了时间。
