赞
踩
本文仅提供思路参考,并非完备的详细设计。
其实很类似IM即时通讯系统,是个变种,本质也是在一个空间内收发消息
type Bullet struct {
UserId int // 用户ID
Content string // 内容
Timestamp int // 弹幕发送时间
Extra *Extra // 效果、样式
}
视频弹幕才有偏移时间,直播应该不用(因果一致性)
读写分离架构,短连接+拉模式
数据结构选择Redis的ZSet
ZADD 直播间ID, 弹幕val, timestamp
(优化:时间只存相对于某个时间点的delta)ZRangeByScore
定时轮询(秒级,准实时即可)持久化
若考虑支持弹幕的回放,数据还是需要持久化,可以考虑使用 MySQL
如果有更高性能的写需求,可以考虑NoSQL DB,如:HBase、OpenTSDB 等
新问题:Write-Behind 这种以cache为主的模式,是可能会丢数据的
使用MQ来消化瞬时弹幕,削峰;弹幕返回条数根据直播间的大小自动调整(热门直播间对时间跨度以及消息条数做更严格的限制)
对弹幕读请求,使用local cache缓存最近5s的数据在应用服务的内存中(过期了才回源redis)
新问题:如果直播间变多,本地内存使用量随直播间线性膨胀,本地cache的命中率下降,还可能频繁触发GC
解决:(1)只针对热门直播间使用本地cache使用“一致性hash”,控制同一直播间尽可能打到同一台服务器,降低本地cache使用量
需要对每个直播间进行指标采样
根据服务器机器资源来分配所承载的热门直播间
此前短连接的方式,每次轮询请求后都要重新建立连接。如果使用长连接轮询,客户端保持连接处于打开状态,就不会一直重新建立链接,减少重复的资源消耗,缩短响应时间。
不过,长连接轮询还是有一些缺点的:
发送者和接收者可能并没有连接到同一个服务器
服务器没有好的方法来判断客户端有没有断开连接
上面MVP版本是拉模式,适合前期;中后期规模和性能要求上来了,需要引入推模式。
为了保障客户端消息的推送性能和实时性,需要引入长连接
Push Server:负责推送(不感知直播业务)
connection proxy:只负责与客户端保持长连接
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。