1.首先实现断点续传功能。
断点续传实现思路：
- 前端对文件分块。
- 前端使用多线程一块一块上传，上传前给服务端发一个消息校验该分块是否上传，如果已上传则不再上传。如果从该断点处断网了，下次上传时，前面的分块已经存在了，就不会重复上传，会在断点处重新上传。从而实现断点续传。
- 等所有分块上传完毕，服务端合并所有分块，校验文件的完整性。
因为分块全部上传到了服务器，服务器将所有分块按顺序进行合并，就是写每个分块文件内容按顺序依次写入一个文件中。使用字节流去读写文件。- 前端给服务传了一个md5值 (前端根据用户上传文件计算出来的md5值) ，服务端合并文件后计算合并后文件的md5是否和前端传的一样，如果一样则说文件完整，服务端可以删除分块的文件，只保留合并成功的文件。如果不一样说明可能由于网络丢包导致文件不完整，这时上传失败需要重新上传。
2.当视频成功上传到分布式文件系统中 (如Minio、oss)，将视频信息保存到数据库的任务表中，表中每一条数据都是一个视频转码任务的处理情况 (包括视频转码状态，完成/未完成)
3.任务调度中心 (如XXL-JOB)，按照任务调度策 (注：这里为了最大化的让多个执行器并行执行任务，采用分片广播的路由策略) 开始调度任务，每个执行器会收到两个值，一个代表一共有多少个执行器，一个代表自己是几号执行器。
4.每个执行器收到了两个参数以后，就知道了一共多少个执行器，及自己是几号执行器。就可以去数据库的任务表中，根据任务id%执行器数量 = 取余结果，找到取余结果等于自己序号的任务。这样可以实现所有任务均分给每个执行器！
这里假设有三个执行器，我要查询执行器1应该执行的任务，未处理和处理失败次数小于3次的任务都可以被作为本次执行器1应该处理的任务，一次最多处理10个任务
5.执行器执行的任务确保都是未进行转码的视频 (通过判断status字段是否为1，比如说1表示待处理)，确保幂等性 (某个视频任务被重复调度后，不会导致某个视频被重复转码)，如果该视频任务是未处理的，执行器就处理该任务。
6.视频转码的逻辑大概就是，由于数据库中任务表里已经存储了该视频在Minio中的信息，就可以从Minio中把该视频下载下来。再使用视频转码工具，如FFmpeg，对视频进行转码。处理完成以后把转码视频上传回Minio中。
7.最后，把对应视频任务的处理结果修改为已完成，并将该记录插入到一个历史处理表中，当前任务表中该记录可以删除。保证任务表中的记录数尽可能的少，因为每个执行器都是从该表中查询自己要执行的任务。
)
