直播弹幕
<p>[toc]</p>
<h1>概述</h1>
<p>互动作为直播中一个非常重要的部分，具有玩法多、流量大、流量不稳定等诸多特点。现对工作中曾经涉及到的玩法做一个总结，温故而知新。</p>
<h1>弹幕</h1>
<p>聊天作为直播互动的基础玩法之一，实时性高，审核严格。可以很好的增加直播间的氛围，增加用户和主播之间的互动率，增加用户的留存率。同时也是互动中非常重要的一个玩法。尤其是双十一天猫晚会等大型活动，接口顺势流量可能瞬间达到峰值（比如开播），或者稳定在某一个水平（非高峰期）。如此大的不稳定流量冲击下，如何保证服务的整体稳定性，非常考验整体的设计。本文将从以下的几个方面来讲述我们的整体设计。</p>
<h2>整体架构</h2>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=59519202f1029d372d5c08ed4b966982&file=file.png" alt="" /></p>
<h2>弹幕玩法</h2>
<p>下面主要看以下在弹幕下的主要玩法</p>
<h3>聊天历史</h3>
<p>场景：直播间开播或者用户点击直播的时候，大量用户同时进入直播间，拉取直播间场次的聊天历史显示，增加直播间的氛围。
特点：热点数据、瞬时流量非常大（QPS 10W+）
针对聊天历史的流量特点，我们采用的方案是<strong>数据预热</strong>+<strong>二级缓存</strong>+<strong>限流</strong>
<img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=bb221098a35af9e64265ab17c9a57cad&file=file.png" alt="" />
因为数据流量非常大的缘故，如果数据直接从RDB中拉取，RDB可能会存在单点问题。所以在服务层增加本地缓存作为二级缓存，在流量尖刺出现之前进行数据预热，将RDB数据同步到服务端的本地缓存中。这样可以将流量尖刺的压力分散到服务端的集群上。这样打到RDB的瞬时流量不会超过集群机器数（由集群热点预热数据的失效时间决定）
限流：在接口层面进行限流，达到阈值后直接放弃请求。</p>
<h3>发送弹幕</h3>
<p>整个弹幕的系统的链路非常长，而且相关的服务依赖非常多，其中任何一个环境的失败都有可能导致整体服务的不可用，而弹幕又是非常高敏的玩法，非常影响用户体验。
特点：链路长，相关依赖服务多，流量尖刺（热点话题）
<img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=63d47ecec3252268d11ba0c8855102c4&file=file.png" alt="" />
针对发弹幕的流量特点，我们采用的方案主要有如下几类。</p>
<h4>限流</h4>
<p>多个维度的限流方案：
接口限流：接口层面的总限流。
业务场景限流：按照业务biz限流
直播间限流：按照业务下直播间进行限流
整体限流架构图如下：
<img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=8e8d04235479ca600236904a35ac0116&file=file.png" alt="" /></p>
<p>多维度多层次的限流方案可以很好的增加服务的稳定性。既能解决平稳流量的问题，也能防止出现流量尖刺。
比如说某个直播间突然火爆了，我们可以调大当前直播间的限流，同时响应的调小其他biz的限流阈值来重点保障黑马直播间。
限流阈值的设定除了很大的依赖于历史数据、接口监控的数据外，还依赖于强依赖的下游服务的可承受能力。
比如说弹幕强依赖于安审系统，如果安审系统QPS限流阈值是200，我们设置2w的限流阈值明显就不合适了。</p>
<h4>服务治理</h4>
<p>在整个的弹幕过程中，前后依赖的服务大概有十多个。针对这些三方应用我们采用了分而治之的策略。
比如直播服务、安审服务、消息服务，属于<strong>强依赖服务</strong>，服务失败整个弹幕就失败了。对于这些服务我们需要做好预热、限流、熔断、降级、重试等策略。
比如用户服务、勋章服务、会员服务等，属于<strong>弱依赖服务</strong>，服务失败并不会影响弹幕的链路。对于这些服务，我们需要做好数据的兜底。比如用户服务失败了，我们可以使用兜底的用户发弹幕。</p>
<h4>消息广播</h4>
<p>A发了一条弹幕,是如何让直播间B，C，D都收到了消息呢？这里使用了集团统一的消息中间件来处理。消息中间件提供基于主题订阅的无线消息群发(保存订阅关系、写扩散)，每个直播间对应一个主题topic，当用户进入直播间时候会给mass发送上行订阅信息（topic+utid）,mass会存放这个直播间（topic）下所有订阅用户的设备id(utid)信息，设备退出直播间时候会给mass发送消息，mass删除该直播间（topic）对应的用户设备。当直播间有用户发上行消息时候，对应业务系统会给mass发一个消息（topic+msg）,mass就会从自己存放的订阅关系中根据topic查询对应的设备列表（utid列表），通过网关sal把msg下发到设备列表里面的设备。</p>