直播已成风口小创业公司如何接受大流量考验?

2019-03-10 来源:未知 责任编辑:-1 点击:

分享到:

  2016 可以看做是“网络直播元年”,随着名人、品牌、网红的加入,一大批移动直播平台获得了长足的发展,其势头不亚于 10 年的“百团大战”,而红豆Live就在这个大背景下应运而生。它是微博子公司有信旗下的一款语音直播产品,旨在为微博大V和意见领袖提供一个知识分享和知识变现的平台。微博覆盖 47 个行业的 230 万垂直大V不仅仅给红豆Live的运营推广提供便利,也带来了对于创业团队巨大的峰值流量。在上线 天,科普大V博物杂志红豆Live首播在线 发布会等直播同时在线 万,直播回放量更是接近 30 万;上线 个月后,两季问答挑战公益直播活动累计在线 万,这些数据见证着红豆Live的成长,也给后台技术团队提出了更高的稳定性和性能要求,而彼时后台团队也只有区区 3 人。

  我们目前后台技术团队的班底来自于微博,大多负责微博平台基础组件的研发。配置中心、分布式消息队列、分布式追踪系统、存储中间件等微博核心中间件的开发和维护大多由我们团队中的成员负责。相比于微博成熟的技术体系,创业团队由于人力资源紧缺、版本迭代快速等原因,在架构上通常具备以下特点:

  1.架构基本以all-in-one方式开始,所有代码打包成一个大工程,减少开发和维护成本

  2.使用成熟的第三方工具、框架和服务支撑业务的快速迭代,技术选型上激进但可控。

  这样的架构支撑下,且考虑服务器的成本,在系统性能上通常不会留有很大的buffer(比如会留 1 倍的buffer),但当面对大型运营活动的大流量时,性能问题就会凸显了。

  在 2016 年 12 月的两次问答挑战大型公益直播活动中,先后邀请姚晨、刘涛、欧阳娜娜、王丽坤等一众明星参与活动,带来了峰值单机接近4000qps的流量。活动中出现大量卡顿和接口访问失败的现象,让我们重新审视架构。

  2.存在明显的热点。不仅个别直播间热点明显,个别接口热点也明显(比如获取直播间人数接口)

  在了解了业务特点之后,我们重新评估目前架构是否能支撑业务。在红豆Live开发之初即采用了服务化架构,如下图所示:

  架构从monolithic architecture直接“跃进”到SOA architecture使我们在服务层面可以做到高扩展性,在架构层面理论上可以承担千万级的访问流量。于是我们从细节上深挖系统瓶颈,以期通过架构上的小修小补实现性能的提升。

  要做到了解系统瓶颈,首先需要搭建一套监控告警平台。我们采用成熟的解决方案:tcollector + opentsdb + graphana来解决接口请求监控的问题。

  1.封装java、python的sdk在发送端合并并且打印监控日志到本机磁盘

  监控系统搭建起来之后,我们对于系统的运行情况和瓶颈有了更深刻的了解,并且在保证版本开发进度的同时,逐一确认解决方案并快速解决。

  从监控中我们首先看到的是接口的热点问题。在红豆Live中存在两个计数:在线人数和观看人数,这两个计数是多个计数的加和,存储在redis中。从访问接口分布来看主要有以下两个来源:

  在运营活动中,此接口会产生5- 6 万qps对于redis的查询,几乎达到redis的性能上限。针对此,我们做了以下优化工作:

  1.分拆读数服务,把它从资源、服务、负载均衡等各层面隔离出来,形成单独的服务池

  2.增加读数的多级本地缓存,本地缓存基于Guava LoadingCache,监控本地缓存的命中率,并且实现缓存时间可配置。这样当面对更大的流量时,可以把流量挡在前面

  经过优化后,redis访问量维持在6000- 8000 的水平线上,并且极大的提升了系统容错能力。

  从目前的架构来看,我们对于接入层、服务层、分布式队列、搜索服务和DB都可以做到横向扩展,但是缓存由于使用的是阿里云提供的服务,无法通过增加从库的方式进行横向扩展,因此只能做到scale up,而不能做到scale out。当大流量涌入时,我们无法对缓存做横向扩展,无疑只能看着系统性能衰减而无能为力。针对此,我们重新对缓存客户端进行了设计,增加了抗量缓存L1。之所以采用抗量缓存而不采用多缓存实例hash的方式,是因为缓存容量很小,多缓存实例会造成浪费,而抗量缓存则可以随时增减。

  红豆server在处理和订单支付相关的请求时多采用异步方式,例如当用户A给主播B送礼物时,会把送礼物作为一个消息发送到消息队列中,由消息处理程序来完成后续的支付、发货(送出礼物)逻辑。但是在异步处理逻辑中却存在着很大的性能问题。

  当礼物订单量增多时,会在消息队列中形成堆积;又由于不同的订单类型放在同一个队列中处理,就会形成交叉影响,严重影响用户体验。

  2.减少对于账户处理中的锁操作,采用定期针对流水结算的方式计算收益,保证账户中收益的最终一致性

  通过以上的优化,我们实现了当礼物订单增长几十倍时,系统的. 99 响应时间控制在200ms左右,礼物发送基本感觉不到延迟。虽然收益的计算存在一定的延迟,但从产品上增加提示后也基本可以满足业务需求。

  以上就是一个小的创业团队针对突发的峰值流量带来的系统架构上的优化总结。当然,当前系统架构肯定不是最好的,但是我们相信架构是改进来的,而不是设计出来的,随着系统流量的增涨,我们也会对架构做持续的优化和演进。

Copyright © 2012-2018 澳门永利国际娱乐官方网站 版权所有