直播架构和feed流架构

一、亿级直播的架构

1、直播整体架构

主要关注业务逻辑。

2、直播业务平台设计

 

3、直播电商业务设计

主播端、观看端

1）后台添加商品

2）主播端

取消置顶、开始讲解

3）观众端

4）高并发设计

常规4Wqps最高400W的QPS直播，电商模块如何设计？

这是一个典型的高并发。

①存储资源设计

存储选型，选nosql，选redis和mc

redis存储设计。商品列表; Key 直播id  value 商品list

详情：key 商品id value 详情，存String 做一个压缩，用pb，减少不少的存储量。

用户和商品的关系：

②容量/QPS评估

如果公司基础设施做的比较好，通过监控、运维，通过监控大盘拉出最近半个月的QPS;

如果没有历史数据可以根据其它业务去评估。

一台redis扛6万的QBS,集群部署，如果是40W，需要7台。需要1.2的buffer，主从 翻倍

③ 接口耗时

算好最低的响应是多少，耗时的地方如何优化；理清调用链；不能拉出所有的商品列表，拉一个置顶商品，使用拉模式；端上下发到网关，再到一些核心流量池，到达业务服务器；查redis资源，把每一步的分部耗时打出来，定位到需要优化的接口；常用的接口优化方案有以下几种：资源层面接口承受的住；优化接口的调用链路，接口的模型调用不准确，优化调用模型；redis扛不住，把数据放到localcache里面；去掉非必要的业务、用并行或者异步。

④ 服务稳定性

如何保障服务的稳定性。

5）直播挑战

① 高并发

除了上面的高并发设计，还有就是有没有服务降级的方案，包括手动降级和自动降级。自动降级是统计QBS，上报降级服务，管理哪些模块需要降级；

快速扩缩容，第一步申请机器，第二部：是调用链路经过了哪些服务，下游服务也需要扩容；

针对极端的QBS来了，可以让有一部分访问不了，流量限制；

如果还是控制不住，那就把redis的热点数据放到localCache里面。放到本地缓存一种是手动，一种是自动；自动用算法，找到热点数据。

业务层面可以做垂直拆分和水平拆分。

② 服务的稳定性

③ 业务复杂度

二、Feed流架构

1、什么是feed流业务

从广义上讲，feed是指为满足用户以某种形式持续得到更新信息的需求而提供的格式标准的信息出口。

微博体系中，feed是指用户通过关注关系，聚合好友，聚合好友最新微博以供自己消费的信息服务，其中也包括分享微博。

2、亿级别用户下的feed流挑战

① 存储挑战挑战

1>如何存储用户发表的微博

2>如何聚合用户关注的微博

② 高并发

3、Feed流核心模块架构方案

feed流架构：

内网核心池：核心池是高配的，硬件资源和带宽都很高，专门存放几个核心接口，这些核心接口QBS比较高。

SLA服务的稳定性和高可用。

4、Feed存储架构设计

1）设计背景（首先了解业务背景）

① 亿级日活用户

② 数据特性是写少读多。百亿读取每天，1亿写入每天。

③ Uid维度，200万/s。

④ 访问规律，热度集中

 85%集中在今天

 95%集中在近两天

 98%集中在近三天

2）存储选型（比对技术以便做出选型）

存储类型	是否持久化	读QPS	写QPS
Mysql	是	单端口2000（SAS） 单端口6000（SSD）	单端口1000（SAS） 单端口3000（SSD）
redis	是	单实例10W	单实例10W
memcached	否	单实例44W	单实例44W
HBase	是	单端口2000	单端口4w

3）存储选型

根据背景做出选型：

持久化：redis、mysql、HBase

并发读QPS：200W/s,采用redis和mc

最近三天热点数据采用mc

全量存储采用redis和mysql。

4）mysql设计

① 传统存储架构方案：

读写分离：1*master+n*slave

如果扛不住做一个水平拆分。

传统mysql架构技术的瓶颈：

热点事件

千万级QPS

数十亿数据存储

② feed流Mysql架构设计

按访问维度分库（承载能力+扩容需求）

按访问维度和时间维度分表（热度+表容量）

部署形式：一主多从，读写分离

集群是以端口划分的；

 

主从机制

自动切换

Backup容灾

③ 一致性hash

影响少部分数据；

Hash偏环，咱们可以做一些虚拟节点；那样影响的数据会很小。

微博不允许数据受影响，所以微博不用一致性Hash。

微博是预估10年后的QBS，把10年后的数据全部申请下来。

5）redis设计

一般是读多写少，写可以用异步rabbitMQ。

分布式缓存会存在什么问题，采用固定hash，接口宕机后会丢掉一部分数据。

5、Feed关注流的推拉模式

1）feed拉模型

优缺点：

优点：架构简单、一致性好、写入过程开销小

缺点：写少读多，网络开销大，资源读取量大。

2）Feed推模型

注：每个用户收到的微博列表

Id0是最新的，idn是最早的。

优缺点：

优点：下行网络开销小，资源成本低

缺点：写入成本高，资源写瓶颈更高。

还有推拉模型。

微博用拉模式，推拉模式业务场景比较复杂，在存储方面用redis和MC,包括存储资源的序列化，存储也包括高频和低频。

6、Feed推荐流的设计方案

如何把用户留下，如何把这些数据存下来给到用户，根据用户画像（包括年龄、地域等标签）推荐给用户相关内容；涉及到大数据分析，如：分析哪个地域的人喜欢互联网，通过大数据分析得出结论，可以给这个地域的人推荐互联网的相关内容。