Skip to content

分片上传投稿+私人影片仓库管理+协同视频流播放/实时消息互动+好友管理+放映室管理

Notifications You must be signed in to change notification settings

emthaibara/joint-cinema

Repository files navigation

scbc.liyongjie.mycinema

分片上传投稿+私人影片仓库管理+协同视频流播放/实时消息互动+好友管理+放映室管理

一.作品概述(功能介绍图)

功能模块.svg

三.整体开发架构

1.前后端分离开发

2.微服务架构

Architecture diagram-2.svg

四.使用工具/技术一览

工具一览.svg

五.核心技术攻关

1.高效上传

未命名.gif
我们所提供的核心体验之一就是自主上传影片,这是我们首要攻克的难点

  - 上传速度要快
  - 反馈体验要好
  - 能妙传判断/续传
  - 开发中----登出/意外断传,关闭窗口/的情况下能续传.....

初步优化:

「我们从一开始的一次性完整传输,到分片+并发+md5校验数据作妙传
前后端需要高度一致的配置,才能完成」
----本地平均250mb/s

进一步优化:

「后台对分片的合并操作利用Java Nio的 FileChannel的transferTo零拷贝优化合并操作,操作执行完毕后,后续的处理(DASH流/缩略图生成)异步多线程执行,快速反馈上传结果给用户」
----本300mb/s(极限可突破)

后期的再优化(开发中):

「尝试后台不再由SpringBoot内嵌的tomcat去处理分片接收,采用基于Netty搭建一个Http协议的分片上传服务器,尝试采用protostuff(可能web端的上传框架不方便使用)二进制流进行传输,在demo编写环节,后期会替换现有的策略」
----目标突破500mb/s的本地传输速率

2.如何执行生成MPEG-DASH流/影片缩略图

image.png
「为了提高放映室的观影体验我们决定采用自适应比特流MPEG-DASH的技术,相比HLS,DASH更具有国际标准/更底的端对端延迟,bilibili与2018年全面采用了MPEG-DASH的技术,如果细心的小伙伴可以发现,看bilibili视频会先一开始模糊再到清楚,这就是自适应比特流」
参考文档pdf(来自谷歌百度):
https://www.w3.org/2019/03/23-chinese-web-jianqiang-bilibili.pdf

  - 工具选用阶段
  - 如何整合进工程内 
  - 如何保证用户反馈

初步策略:

「采用FFmpeg生成MPEG-DASH流和缩略图的生成(默认为2min处截图),又Java去调用外部程序,执行FFmpeg的相关命令」

初步优化:

「由于Java提供的执行外部程序的缺陷,经常会出现Runtime缓冲区问题导致的线程卡死,我们引用Apache Commons-Exec工具来执行外部程序,并且异步多线程的形式去执行DASH流生成以及缩略图生成的业务」

整合策略:

「该两项业务与上传业务密切挂钩,但又属于相互独立的业务,以及微服务开发的架构,我们进行了业务拆分,将上传与该两项业务独立于两个SpringBoot工程,通过rpc相互调用,保证业务的完整性」

优化RPC调用:

「初期采用Fegin来完成两项业务之间的调用,但经过调研和学习发现,谷歌提供的Grpc速度更快,效率更高,可以提高我们带给用户的反馈,我们决定选用Grpc作为我们远程调用的框架」
-----gRPC基于Netty+Http2.0+Protocol Buffers比传统的RPC要快60%以上

后期的再优化(开发学习当中):

「通过cdn加速,视频点播服务,云存储技术优化用户的观影体验,还有视频存储的策略也需要升级改造,还有一系列的问题和考验需要我们去解决和面对」

3.协同播放与实时通知

受文档大小限制画质会比较糊

gif.gif
实时通知: 在该作品中会出现很多这种业务,好友申请发起/视频分享申请发起/放映室创建邀请发起/
_实际上还有一个业务----__在线/离线 判断,_我们相对的业务逻辑也就不一样

策略:

「用SpringBoot整合一个基于Netty开发的WebSocket服务器,用来创建长连接,主动推 送信息给客户端。利用这种特性,我们实时传播房主发出的开始/暂停等操作,从而实现协同 播放。」

难点:

「需要维护一个User--Channel的双向映射的Map,才能完成精准的消息投送,服务器每接收到一个活跃的连接,首先需要客户端发送一个BindAskMessage来通知服务端将用户Channel绑定,用户的基本信息来自BindAskMessage实体类内部(这里对每一种消息类型都做了一个封装)」

优化:

「我们将建立两个Netty搭建的WebSocket服务器,一个用于处理主页的相关事务,一个专门处理放映室协同播放/实时聊天的事务,减轻单个服务器连接的压力,和Bind信息混杂不好管理的问题」

后期优化:

「协同播放追求低延时,在实时传递开始/暂停/实时聊天等业务的时候,传统的Json.xml.java对象不如protobuf的性能更高,延时也就更低,后期我们将放映室的数据传输用protobuf替代」

4.UUID生成器

在该作品中存在很多需要UUID作为唯一标识的场景,视频uuid/仓库uuid/房间号uuid等等

生成策略:

「采用github开源的JUG(java-uuid-generator)JUG 可以在每个内核每秒生成数百万个 UUID,有时达到每秒 1000 万个的理论极限」

5.缓存

策略:

「选用Redis作为缓存数据库,缓存一些离线消息/放映室的初始化数据/等等」

6.统一认证

策略:

「Spring cloud gateway + JWT Token + Redis 的网关统一验证身份,在gatetway内构建一个Global Filter 用于拦截请求,验证token的时效性,合法性,redis在这用于缓存token---user相关信息以及token---secret」

六.Base-Api

接口.svg

About

分片上传投稿+私人影片仓库管理+协同视频流播放/实时消息互动+好友管理+放映室管理

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published