parallelpan /
先说清楚这个仓库是什么、不是什么：它公开的只有系统架构、交付链路与工程实践文档（含界面截图），不提供可执行代码、内容获取工具或破解方法，文档与截图采用 CC BY-NC 4.0（可转载署名、不可商用）。项目是第三方非官方的，与红果、字节跳动及其关联公司没有任何关系，未获授权或认可。线上另有一个可体验的网页服务作为对照，按实际取件集数计费。 写这份文档的起因是一个很具体的工程问题：短剧平台只提供「在 App 里一集一集看」，没有全集导出。…
先说清楚这个仓库是什么、不是什么：它公开的只有系统架构、交付链路与工程实践文档（含界面截图），不提供可执行代码、内容获取工具或破解方法，文档与截图采用 CC BY-NC 4.0（可转载署名、不可商用）。项目是第三方非官方的，与红果、字节跳动及其关联公司没有任何关系，未获授权或认可。线上另有一个可体验的网页服务作为对照，按实际取件集数计费。 写这份文档的起因是一个很具体的工程问题：短剧平台只提供「在 App 里一集一集看」，没有全集导出。想把一部上千集的长剧变成一套可留存的文件，难点其实不在「下载」这个动作，而在长任务怎么编排、失败怎么恢复、以及最后那个几 GB 的 ZIP 怎么在不落盘的前提下发出去。 仓库里记录了三个带生产实测数字的案例： 1. 1000 集长剧，85 秒完成交付。下载阶段 worker 只上传分集文件，不同步打整包；每集独立状态，失败自动重排、已完成的跳过，任务在约 85 秒就变为「已完成」，用户可以立即取件。整包改为收尾时按需生成。 2. 双支付通道的对账不靠人盯。币安 USDT 走金额尾差指纹，Stripe 走自动查单；两条通道不共用同一套指纹池，再配合 24 小时补确认窗口，避免同金额订单串单。 3. 实例被摘除，75 秒自愈。单机自愈架构（伸缩组 MIN=MAX=1 + 自定义镜像 + Tunnel，源站不开公网端口），故障演练附完整时间线。一个反直觉的运维约束也写在里面：有任务在跑时只重启 API、不能重启 worker，否则 SIGTERM 会让任务永久卡在 running。 几个我觉得对做类似系统最有参考价值的坑： 上游会混发不同封装的分集。一部分分集用私有封装的编码容器，流内缺少标准参数集，通用工具会直接报不支持；另一部分其实是明文流。所以流水线不能靠「有没有密钥」判断能不能处理，下载后要先识别封装类型，再决定重编码还是直接 remux。 整包打包不能「先把对象列出来、再一起开连接」。888 集会一次打开 888 条对象存储连接，被判空闲后断连，表现为 IncompleteRead。改成同时只开一条、断读后按已读字节续读，4.26GB / 888 集约 114 秒稳定完成，且全程不落盘。 解码校验不能当成交付门槛。20 秒超时后要换成跳过环路滤波再验一次，双超时才放行；否则会把本来能播的成品误判成失败。 发版和镜像是两件事。伸缩组重建看的是「生效伸缩配置」里的镜像 ID，只发代码不刷镜像，机器一回收就回退；线上代码只来自某个 tag 的 git archive，一次上线一个 tag。 首屏 SSR 是前端的逐字镜像。导航、页脚、首屏骨架在后端另有一份，改前端不同步改它，水合时会闪一下；后来加了一条自检：关掉 JS 的截图和开着 JS 的截图应几乎一致。 技术栈大致是 Python + FastAPI、React + Vite、对象存储，加上独立的转码 worker 队列；文档里有架构图和各环节的职责划分。 适合谁看：在做长任务队列、转码流水线、对象存储流式打包，或者想把一个「要跑几个小时的活」包装成网页服务的人。文档里的数字都是生产实测，不是压测推演，也记了不少走错的弯路。 限制与声明：仓库仅用于展示产品设计与工程实践，不提供任何内容获取工具、破解方法或可执行代码。内容版权归原权利人所有，使用者应自行确保对所处理内容拥有合法权利，并遵守所在地法律法规与平台服务条款。文档不可商用，仓库只接受文档纠错类 issue。
Discuss this product