qs的文件下载策略
开始
- 基于Python的小文件下载是非常简单的:
1 | import requests |
- 但在实际应用时,这样的简单文件下载往往不满足生产需要。比如,
单线程下载速度慢
,IO频繁
。玄学的是有时候这个可能比多线程下载要快一些。
普通文件下载策略
如何分配线程数?
- 在使用qs下载时,首先判断当前系统的
CPU
状态,保证在调用min(CPU核心数*4, 16) + max(CPU核心数/2, 2)
的线程数情况下,平稳下载。其中,max
部分是写文件线程池,用于处理频繁的文件IO。
如何针对一个文件并行下载?
- 利用http通讯协议,在http头部信息添加
range: bytes=from-to
信息,对一个文件分块下载。 - 既然可以分块,块与块之间又没有依赖,就可以进行并行优化。并且,得益于文件操作的位置不同,甚至不需要针对下载文件设置读写锁。
- 当然,这样下载有一个前提,就是需要预先知道待下载的文件具体有多大。所以,在无法预知文件大小时,qs仍然会采用
最朴素的下载方法
(也就是开篇的那个算法)
如何设定块大小?
- 经过反复测试,我认为相对性能较好的块大小区间:
- 很多时候,下载的文件其实并没有很大,针对大小不足
5M
的文件,qs不会启用多线程下载。
下载中途可能的问题
- 针对块下载时可能遇到的意外错误,
qs
将无限制的重试下去。如果重试次数达到一定数量,每次重试时qs将小憩一段时间。 - 在一些并不稳定的下载过程中,遇到网络波动下载进程终止是很麻烦的事情,但是,你不用为qs担心,在启动多线程下载时,qs会将下载过的块进行标记并将信息存储在以
.qs_dl
结尾的文件里,当你重新进行文件下载时,qs可以实现断点续下载
。 - 具备下载限速的资源,多线程下载加速并不十分明显。过快的下载速度+低速的内存可能会造成下载过程中qs占用过多内存的问题。
qs下载的优势
断点续下载
- 得益于分块策略,可以大幅提速
不会被意外的网络问题中断下载任务
qs针对每一块下载都设置了超时重试,这意味着网络状态突然改变时,qs性能不会一直受到影响。
将尝试的优化
- 动态调整块大小。
- 增强程序健壮性
部分源码
1 | ... |
流媒体下载策略
- 经常开车的小伙们总会需要下载一些流媒体,其视频信息往往存储在以
.m3u8
结尾的索引文件中; - qs可以识别出这类文件,并启用线程池并行下载索引文件中的所有
.ts
文件,并帮助你把.ts
文件们合并(但是并不保证这个过程一定没有错误,可能会造成你转换视频格式时出现问题)
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 RhythmLian's Blog!
评论