1 给视频发送弹幕的功能 非常常见，比如说b站。在我们在线实习项目“推评分”的推剪辑短视频模块 ，为了wuga与竞品豆瓣的用户定位区别，年青人更喜欢弹幕的交互，产品就增加了弹幕功能

但是在线实习的java实习生在发送弹幕接口的设计上 核心问题没分析好，所以设计不能实际使用，就不要讲上线了

古人说的好：任何中间件的引入， 都不是凭空的，都是流量和系统压力的转化

所以业务设计 一般都是按正常的普通流量去分析，把整个流程理清楚，然后再看系统未来半年左右的流量 去看哪些点需要优化

而不是流程还没想清楚 ，上来就拿着其中一个点 说可以上什么技术，工作中不是这个样子滴

1 正常流量

发送弹幕接口

 -》1 接口幂等 防止前端防抖没做好 单个用户提交两遍 这个是流量大小无关

-》2 文本非法校验 这个因为项目已经有相关接口，这里不是重点

-》3 插入数据库，所有同学的设计 都是一条一条的插入

这里逻辑上还有一个问题，就是弹幕是跟视频播放的某个时间绑定的，是有排序的

如果只是一条条插入，拉取的时候如果有分页 或者整个拉出来再排序 那对性能的影响肯定是有的，但是多大，要按数据量分析

所以设计发现 不是说发送接口 就只考虑发送 还要考虑整体 读取的接口的考虑

2 流量变大

弹幕有一个特点，就是可能会出现爆款，就是有几个短视频 忽然火了，哪怕我们是创业项目 平台人数不多，但是高峰期 上万个短视频 一秒只是发送接口 上限就会在100次以上

注意整个项目不是只有一个发送接口

所以就出现两个核心问题 1 不能高频插入数据库，连接数不够 2 数据库里弹幕的时间排序有性能问题 如果加上一个排序字段 那每次插入都可能会浪费时间

那方案就会改变

1 不能直接插入数据库 很简单 那就先放Redis里呗

但是问题又出来了 ：

（1）放redis里 是不是跟已有的弹幕直接合并？那非法校验什么时候做？那时间排序是不是每次都要做？

（2）非法校验会不会量大之后 影响同步，可不可以异步 可以-》短视频的弹幕不需要实时返回结果

（3）新增的数据怎么同步落地到数据库，如果数据库还是一条一条插，那数据库还是连接数不够 ？正常业务也不是说过两分钟 数据库就没压力了 延时在正规业务是没有用的

所以先要变更的是数据表的设计，就不能一条一条插入，而是改为一个视频只有一个字段 用json放时间格式的已经排序好的数据，这样同步也好 拉取也好 就非常简单 一条查询

最终方案见视频末：大家可以讨论下