Twitter分片文件上传架构及类Twitter应用到S3的上传方案问询

针对你提到的暂存方案选型以及高流量站点的通用实现，行业内的落地逻辑如下：

• 你当前使用的内存暂存全部分片的方案完全不适合高流量场景，并发量上来后很容易触发OOM故障，仅能用于极小文件、极低流量的测试场景。
• 你提到的本地磁盘暂存方案也不是高流量站点的选择，会存在单节点磁盘IO瓶颈、多节点部署时分片散落在不同服务器、磁盘故障丢分片的问题，仅适合小团队低流量的小型应用。

高流量平台的通用实现分为三类，可根据业务需求选型：

• 流式透传方案（无暂存）：这是中转场景下的首选方案。你可以在收到客户端第一个分片请求时，直接向自有S3服务申请Multipart Upload上传ID，后续每个分片从客户端接收后不需要落地，直接以流的形式同步转发到S3的分片上传接口，所有分片传输完成后调用S3的complete接口合并文件。该方案仅需要为当前传输的分片分配几MB级别的内存缓冲区，完全不占用本地磁盘资源，性能和并发承载能力最高。
• 分布式临时存储方案（按需暂存）：如果你的业务需要在文件上传S3前做预处理（比如内容审核、图片压缩、视频转码），才需要做临时存储，不会存储在单台Web服务器的本地磁盘，而是将分片写入分布式缓存（比如Redis集群，适合小文件分片）或分布式共享存储（适合大文件分片），预处理完成后直接上传S3，同时删除临时分片数据，避免单节点故障丢数据，也方便水平扩容。
• 预签名直传方案（无中转）：这是Twitter这类超大规模流量平台的主流方案，不需要走自有Web服务做中转。你只需要在客户端发起上传请求时，后端校验用户权限后生成S3预签名上传URL返回给客户端，客户端直接将文件上传到S3，S3上传完成后回调你的业务服务做后续逻辑处理。该方案完全不占用自有Web服务的带宽、存储、计算资源，成本最低，并发承载能力最强。

补充注意：如果你的合规要求必须走自有服务中转，需要额外做分片上传的幂等校验，将上传进度持久化到分布式缓存中，避免客户端重传时重复传输分片，同时解决多节点部署时分片跨节点无法合并的问题。

内容的提问来源于stack exchange，提问作者qubicswap.com