网易云一面系统设计题：直播弹幕系统_哔哩哔哩_bilibili

网易云一面系统设计面试题分享，好久没讲啦有点嘴生脑生了～直播弹幕系统设计：https://blog.qizong007.top/article/live-streaming-bullet-system网易云一面面经：https://blog.qizong007.top/article/net-ease-cloud-music-interview-1, 视频播放量 45、弹幕量 0、点赞数 1、投硬币枚数 0、收藏人数 2、转发人数 1, 视频作者 _王帅真, 作者简介 分享编程与思维认知 https://blog.qizong007.top，相关视频：动画学Redis分布式锁，超多动画，锁订阅、锁续期、Lua原子执行原理、顺便讲Sync锁升级，Leader:明天谁在用Arrays.asList 谁就卷铺盖走人，网易云音乐挂机项目，单窗口收益40-60（稳定不封号），愚人节最好笑的笑话，【Tech Bite】系统设计篇：5分钟搞懂垂直扩展与水平扩展，【读书分享】《卓有成效的工程师》02-精益求精，优化学习方式，面试官:MySQL中IN是全表扫描吗？，校招ssp是什么水平？同样是八股，看看自己和up对同样知识在理解和表达上的偏差。校招Java开发面试实录。，Spotify满血版！整合所有配套，从此听歌体验拉满！，【Tech Bite】系统设计篇：5分钟搞懂负载均衡

https://www.bilibili.com/video/BV1db421a7K8/?spm_id_from=333.337.search-card.all.click&vd_source=7beff1314e75b11a8c966357e829e678

特点

其实很类似IM即时通讯系统，是个变种，本质也是在一个空间内收发消息

• 消息及时性强，过期消息意义不大

• 用户松散，随时来随时走

• 可能有瞬时大批量弹幕（比如比赛精彩部分）

• 流量特点：读多写少

弹幕数据结构

视频弹幕才有偏移时间，直播应该不用（因果一致性）

MVP版本

整体设计

读写分离架构，短连接+拉模式

• 写：若不考虑历史弹幕可回放，可以直接使用 Redis 作为唯一存储

• 读：Redis 主要用于读缓存，缓存直播间最新的弹幕数据

存储

• 需要弹幕按时间排序，而ZSet可保证有序

• 此外，score允许重复，那我们就用timestamp来做score

使用

• 发弹幕：ZADD 直播间ID, 弹幕val, timestamp（优化：时间只存相对于某个时间点的delta）

• 拉取弹幕：ZRangeByScore 定时轮询（秒级，准实时即可）

问题

1. 弹幕怎么持久化（Redis扩容成本高）

2. 热门直播会有大量瞬时弹幕，挑战Redis并发瓶颈

3. Redis重复请求多，相同直播间会存在很多重复的轮询请求

问题cover

1. 持久化
1. 若考虑支持弹幕的回放，数据还是需要持久化，可以考虑使用 MySQL
1. 弹幕在直播结束后迁移至 DB（可以专门拿一台从redis做回放）
2. 异步刷入（开线程/监听redis日志刷/发MQ消费）
2. 如果有更高性能的写需求，可以考虑NoSQL DB，如：HBase、OpenTSDB 等
3. 新问题：Write-Behind 这种以cache为主的模式，是可能会丢数据的
1. DB挂了，少写数据，但是只要数据还在redis能追回来
2. redis挂了，服务感知到后降级，请求回源，“缓存击穿”

2. 使用MQ来消化瞬时弹幕，削峰；弹幕返回条数根据直播间的大小自动调整（热门直播间对时间跨度以及消息条数做更严格的限制）

3. 对弹幕读请求，使用local cache缓存最近5s的数据在应用服务的内存中（过期了才回源redis）
1. 新问题：如果直播间变多，本地内存使用量随直播间线性膨胀，本地cache的命中率下降，还可能频繁触发GC
2. 解决
1. 只针对热门直播间使用本地cache
2. 使用“一致性hash”，控制同一直播间尽可能打到同一台服务器，降低本地cache使用量

优化：热门直播间

• 需要对每个直播间进行指标采样
• 标准：粉丝数、在线粉丝数、是否有活动
• 弹幕系统需要与直播间系统隔离
• 请求时带上直播间的“热门”标识

• 根据服务器机器资源来分配所承载的热门直播间

长连接轮询

• 发送者和接收者可能并没有连接到同一个服务器
• HTTP协议的服务器通常是无状态的，如果使用Round Robin的方式来做负载均衡，接收到弹幕的服务器可能并没有与等待接收消息的客户端保持长轮询连接

• 服务器没有好的方法来判断客户端有没有断开连接

架构图

推模式

上面MVP版本是拉模式，适合前期；中后期规模和性能要求上来了，需要引入推模式。

架构图

长连接推送

• Push Server：负责推送（不感知直播业务）
• 存储：从 Redis 中获取用户和直播间的关系以及长连接信息
• 推送：分批并发推

• connection proxy：只负责与客户端保持长连接

使用技术

• WebSocket（HTTP 2.0支持的全双工通信+长连接）

• Session（基于redis，通过用户会话来推）

优化

• 有状态服务需要做好路由

• 两个批量推送：消费 MQ 后批量推；从 push server 到连接代理的每个连接上也批量

• 推拉结合，可以把短连接的拉作为长连接推的降级方案（服务端监控+客户端上报）

其他挑战

• 写扩散（m条消息*n次扩散，平方级别）⇒ MQ控制推送速率

• 丢弹幕 ⇒ push 失败引入重试；落 DB 引入 ACK

• 带宽压力

• 灰度拉切推

其他思路

• 使用 redis 的 Stream 来做弹幕的发送（生产）和阅读（消费）

• 前端展示上的优化
• 弹幕去重
• 发送弹幕后，本地优先展示（即使它丢了 or delay）