直播行业前景分析和直播平台业务简介
从上图可以看出，随着直播行业多年的发展，当前行业已经进入稳定的增长阶段。虽然年增长率有所下滑，但也说明了直播行业已经越发成熟，未来行业将更加注重精细化和专业化的运营，对于平台来说，更精确的内容推荐就显得尤为重要。另外，整个直播行业还有以下几个趋势
直播+商业模式创新，孵化出了更多的细分领域，比如直播电商，钉钉企业直播等
直播出海程度加深，大型直播平台可能会寻找海外业务增长点
随着5G时代到来，直播行业可能会有更大的市场
直播的核心在于音视频编解码等相关技术，看起来和数据库关系不大。泛娱乐直播作为一种视频信息的传播形态，经过多年的发展，已经有非常丰富的内容和玩法。要构建一个完善的泛娱乐直播平台并不容易，但存在一定的共性，一些核心的业务功能和需求如下图，只要涉及数据存储，就无法避免和数据库打交道了。
后续我们会对这些直播的业务场景具体展开，逐一分析这些场景对应的数据库选型和最佳实践。
直播平台对数据库的主要挑战
流量洪峰
当存在大型赛事直播或超高流量主播入驻等情况时，热点直播间在线人数/QPS流量会存在数倍甚至数百倍增长，这需要系统提供超强的弹性扩容能力。
主播/粉丝关系庞大
社交属性是泛娱乐直播平台的强需求，而实现诸多社交功能的基础是健壮的关系服务系统。用户关注一个主播时，后端会产生若干条数据，当用户数量达到上亿规模后，后端的关系数据可能达到千亿级以上，这无论对于数据存储还是流量，都是一个巨大的挑战。
实时性&稳定性要求高
与综艺网剧，短视频等相比，直播最大的吸引力在于实时互动。在直播间中，观众的点赞，评论，打赏，直播间的人气统计，各类实时排名和主播PK结果等信息对系统RT都有很高的要求，甚至无法接受系统的轻微抖动，这对后端数据库的性能和稳定性是个双重考验。
直播平台数据库选型的整体思路
从上文的泛娱乐直播平台的业务介绍和需求分析可以看出，构建一个完善的直播平台较为复杂，无法只使用单一的数据库产品实现所有的需求，需要涉及到较多的数据库产品。
其中Redis在直播平台中占据了一个非常重要的位置，主要用于处理超高频的查询业务，以及合理利用Redis带来的一些独特的数据结构可以在保证性能的同时，极大地简化业务流程。阿里云Redis提供了较为丰富的Redis产品形态以满足不同场景下的需求，在Redis相关产品选型中，Redis能够承载的QPS评估是重中之重。我们做一下简单对比，比如阿里云Redis社区标准版能够承载的QPS为K(社区标准版性能基本上与社区开源保持一致，基准压测的情况下一般在10w左右)。
en |
Redis社区版 集群 |
Redis社区版 读写分离 |
Redis企业版-性能增强型 主备 |
Redis企业版-性能增强型 集群 |
Redis企业版-性能增强型 读写分离 |
写（key均匀情况） |
K*分片数 |
K |
K*3 |
K*3*分片数 |
K*3 |
读（key均匀情况） |
K*分片数 |
K*只读节点数 |
K*3 |
K*3*分片数 |
K*3*只读节点 |
写（热key） |
K（最坏情况） |
K |
K*3 |
K*3 |
K*3 |
读（热key） |
K（最坏情况） |
K*只读节点数 |
K*3 |
K*3 |
K*3*只读节点 |
通过上图可以看出，在产品架构层面，Redis的产品形态选型非常直观，即在满足业务流量的大前提下选择价格最低的，当然阿里云Redis支持在标准主备版，读写分离版，集群版之间互相一键平滑转换。在直播平台的架构中，热点直播间和热点主播不可避免，针对这部分无法均匀的业务流量，就非常推荐使用Redis企业版-性能增强型了。
直播场景分析和解决方案
各类粉丝排行榜
在各类直播间业务中，各种排行榜的业务非常多，大概可以分为两种，一种是非实时的排行，比如用户维度的贡献周榜/粉丝总榜单；另外一种是实时的排行，比如大型活动中的实时PK排行，当日粉丝的亲密度排行等。无论是历史排行还是实时排行，Redis都是最佳选择。
利用Redis的Sorted Set类型实现实时排行
因为Sorted Set中的元素始终是按照score值进行排序的，所以其天然适用于实时的排行榜类系统。举个例子，在大型比赛中要对主播热度进行实时排名，使用Redis的简单指令即可轻松实现
通过zadd初始化该直播间的热度
通过zincrby实现直播间热度+N
通过zscore获取某个直播间的热度值
通过zrank获取某直播间热度的排名
通过zrevrange获取热度Top N的直播间
通过zrem删除某个敏感&违规的直播间
利用Redis的List类型实现定时排行
List类型的lrange命令可以分页查看队列中的数据,但是只有定时计算的排行榜才适合使用list类型存储,相比实时排行的sorted set，它更节约内存资源。例如将上周一至周日计算出的用户在某个主播上的消费金额作为该主播的粉丝周榜数据存入list，那么在下周一0点更新数据前，从list中读取出的数据列表就是上周的粉丝贡献周榜。
用户关注列表
用户的关注列表/最爱等功能是直播间业务的核心功能之一，通常获取用户关注列表是非常高频的，而修改相对较少，列表长度有限，基本不存在热点的情况。可以将用户的关注列表存储在Redis的Hash结构中以实现缓存的功能，轻松应对超高并发流量。
热门直播间业务
开播瞬间流量洪峰，热门直播间相关的QPS飙升，直播间与主播是一一对应的。如果这时还是沿用之前的Hash结构存储热门直播间的数据，势必会造成该Hash Key过热，进而导致该Key所在的Redis分片同样过热，影响到其他Key的正常业务。
这时需要尽可能将主播信息拆成多个属性存储，使用集群/读写分离分担热门主播的流量。另外使用Redis存储主播的基础数据，并设置永不过期，从而避免在Cache Miss的情况下打爆底层的持久化存储。
直播间在线人数实时统计
相比关系型数据库而言，Redis在实时计数方面存在天然优势。在关系型数据库中，实时计数操作的本质就是单行更新，而由于行锁的存在，任何关系型数据库的热点行更新必然是瓶颈，社区版MySQL热点行更新的TPS在500左右，这对于突发流量巨大的视频直播业务是无法接受的。阿里云企业版Redis-性能增强型可支持20w以上的热点行更新能力，可以圆满抗住大V主播开播瞬间带来的观看人数飙涨的场景。
点赞/收藏/踩相关的业务
在视频直播平台存在诸多的点赞和收藏相关的需求，如果使用传统的关系型数据库存储，那么将其抽象的两个最高频的SQL为
展示视频的点赞或收藏数量，并不可重复点赞和收藏(select uid from dianzan_table where vedio_id=YYY;)
展示用户的点赞和收藏列表(select vedio_id from dianzan_table where uid=XXX;)
由于这是多对多的业务模型，即一个用户可以对多个视频点赞，一个视频也可以由多个不同的用户去点赞，当业务发展到一定阶段，这张表的数据量也将会非常大。这时如果考虑传统的分库分表方案，无论使用vedio_id还是uid存储都无法兼顾另外一种查询。
优化思路
使用Redis计数器实现点赞数量+1
当数据量膨胀至单机存储不下的情况，使用PolarDB-X全局二级索引，实现视频id和用户id两个维度的RT保障
使用RedisSet存储点赞列表和点赞去重(SADD SISMEMBER)
直播间小游戏/轻量日志分析
直播平台可能存在诸多社交小游戏，小游戏的开发更强调快速的开发能力，且游戏中的角色和装备等业务属性在数据建模上多采样半结构化，MongoDB的schema-free特性非常贴合此类需求，可以助力业务方迅速完成小游戏开发。此外，MongoDB自带的TTL索引特性在小游戏道具自动过期删除等方面也存在的一定的优势。
几乎任何应用运行过程中都会产生大量的访问日志，必要的日志和监控存储不仅有利于系统故障分析，部分日志还存在很大的分析价值，比如直播平台中的用户登录日志，回流用户的礼物领取日志，系统运行日志等，使用阿里云数据库MongoDB的灵活文档模型+Aggregation Pipeline和能力，可以快速构建一个健全的日志采集和分析系统
直播业务指标监控
监控数据都存在天然的时间属性，直播平台当然也有业务指标监控的诉求。使用云数据库TSDB存储海量日志和监控类数据，阿里云TSDB在高度兼容OpenTSDB协议的基础上，采用自研的索引，数据模型，流式聚合等技术手段提供了更强大的时序能力，并且在运维管控和存储成本方面均存在一定的优势。
直播平台的交易系统/关系服务等核心业务数据存储
在视频直播平台中，任何需要持久化，事务处理的业务都建议存储在关系型数据库中，比如涉及到公司核心资产的用户中心，涉及到用户交易相关的虚拟货币系统，平台对账和分账。建议根据业务数据量和QPS的不同使用PolarDB-X和RDS-Mysql。
在视频直播平台中关系服务的设计和选型至关重要。当关系数据超过10亿时，要应对数据存储容量瓶颈和超高并发的数据请求，分布式设计是一个必然的选择。在视频直播平台的分布式数据库选型上，需要重点考虑以下问题和场景，这也是大部分分布式数据库中间件无法满足的
分布式事务支持，且底层存储的数据强一致。这对于直播平台的用户充值，用户送礼等事务行为是硬性需求，PolarDB-X支持强一致分布式事务，确保分布式事务全局读写强一致,且使用体验与单机MySQL数据库一致，无需特殊指令开启
多维度的系统扩容能力和紧急故障处理能力。当大V直播入驻或大型活动赛事时，可能会带来系统突发的高并发流量，任何一点都可能是瓶颈，也许瓶颈是proxy层面，也许是数据存储计算层面，也许是CPU资源，也许是IOPS不足。PolarDB-X采用分层架构可确保在并发、计算、数据存储等多个方面均可线性扩展，通过增加PolarDB-X计算资源与存储资源以达到水平扩展效果。而在故障诊断和处理方面，PolarDB-X集成了完善的SQL审计和聚合分析，能够在最快的时间内定位到问题。
MySQL协议兼容程度。处于成本考量，在直播平台发展初期，大部分业务都会选择单机的RDS MySQL实例。而当业务量上涨到需要分布式数据库时，如何有效兼容现有RDS MySQL的使用习惯和功能支持的完整度非常关键。PolarDB-X兼容MySQL生态，对于主流的客户端、驱动有着良好的兼容性，SQL语法兼容完善，业务可快速进行对接适配，并且在数据的在线迁移上，通过DTS即可实现一键平滑迁移。
送礼业务/关系服务等架构优化
对于“荷尔蒙”消费的直播平台来说，久久没等到小姐姐的一声谢谢，可能会出大问题。由于直播平台用户以uid做水平拆分，那么在送礼侧几乎不会存在瓶颈，上千万关注的大V主播，可能有N多用户同时对齐送礼，高并发的收礼就演变成了数据库中常见的热点行更新，这时如果强行使用数据库的分布式事务和社区MySQL的单行更新实现，可能导致在数据库侧的巨大瓶颈。
优化思路
使用阿里云数据库的热点补丁，10倍以上的热点行更新能力
使用消息队列做异步化处理，将送礼和收礼拆分成两个单分片事务。在海量关系服务的设计上同样如此，当用户关注一个主播时可能产生若干条数据，可以将关系服务拆分为“用户关注服务”和“主播粉丝服务”
用户标签/直播内容推荐/大数据分析
在视频直播行业，当业务发展到一定程度，实时的大数据分析必不可少，比如主播平均播放时长分析，用户观看时长和观看内容分析，用户的充值行为分析，留存率分析。通过数据分析结果来制定对应的运营策略和战略，从而把控产品正确的发展方向。
推荐使用阿里云AnalyticDB"一键建仓"功能，通过简单几步配置即可将RDS、PolarDB、日志服务或者日志服务中某个日志库中的数据快速同步到AnalyticDB集群中，然后通过Quick BI进行实时可视化数据分析。相对于传统的关系型数据库，AnalyticDB只需要毫秒级时间，即可实现万亿数据高并发多维实时分析。
直播平台的异地多活/政策风险规避
与大多数行业一样，大型直播平台同样数据库存在异地多活的需求，在这一块阿里云数据库有较为成熟的方案和技术，但实现较为复杂，这里不多赘述。
另外在直播出海这块，为了规避可能到来的政策风险，比如美国封杀令，可能需要将数据随时可以传输至海外的其他区域，比如像新加坡这种相对开放，稳定又合规的环境。基于以上问题，可以以新加坡为中心，使用阿里云DTS，走阿里云骨干网络将全球数据传输至新加坡中心。
