特点

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

弹幕数据结构

type Bullet struct {
	UserId    int // 用户ID
	Content   string // 内容
	Timestamp int // 弹幕发送时间
	Extra     *Extra // 效果、样式
}

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

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

数据结构选择Redis的ZSet

持久化
1. 若考虑支持弹幕的回放，数据还是需要持久化，可以考虑使用 MySQL
  1. 弹幕在直播结束后迁移至 DB（可以专门拿一台从redis做回放）
  2. 异步刷入（开线程/监听redis日志刷/发MQ消费）
2. 如果有更高性能的写需求，可以考虑NoSQL DB，如：HBase、OpenTSDB 等
3. 新问题：Write-Behind 这种以cache为主的模式，是可能会丢数据的
  1. DB挂了，少写数据，但是只要数据还在redis能追回来
  2. redis挂了，服务感知到后降级，请求回源，“缓存击穿”
使用MQ来消化瞬时弹幕，削峰；弹幕返回条数根据直播间的大小自动调整（热门直播间对时间跨度以及消息条数做更严格的限制）
对弹幕读请求，使用local cache缓存最近5s的数据在应用服务的内存中（过期了才回源redis）
1. 新问题：如果直播间变多，本地内存使用量随直播间线性膨胀，本地cache的命中率下降，还可能频繁触发GC
2. 解决：（1）只针对热门直播间使用本地cache使用“一致性hash”，控制同一直播间尽可能打到同一台服务器，降低本地cache使用量

此前短连接的方式，每次轮询请求后都要重新建立连接。如果使用长连接轮询，客户端保持连接处于打开状态，就不会一直重新建立链接，减少重复的资源消耗，缩短响应时间。

不过，长连接轮询还是有一些缺点的：

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

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

为了保障客户端消息的推送性能和实时性，需要引入长连接