请问关于文件上传系统设计,怎么设计并发问题处理的

[DeepDarkVan]

目前老板又给了我个私活,写一个文件传输的中台,文件存储服务对接的是微软的 Blob.目前流程是:1.由中台接收前台的上传请求校验后授予上传凭证,前台通过上传凭证直接上传文件到微软的 Blob,然后再通知中台上传成功. 2.由前台直接上传文件到中台,中台再上传到微软 Blob. 大佬们,这系统设计针对大批量请求可以异步处理嘛

[w504391883]

感觉方案一更加合理一些，而且中台不是很需要考虑并发得问题，方案一并发上来得话只要解决请求凭证问题就可以了，瓶颈在 Blob，不在中台

[oxromantic]

肯定方案一啊，方案一客户端传成功了就铁定成功了，方案二你还得做和 blob 的异常处理流程，客户端传了个 100%还得等你和 blob 的交互完成

[fengpan567]

方案 1 省事

[jswh]

文件上传问题在于并发时候的带宽，所以有服务商了实际的上传肯定是丢给服务商的服务器了，自己做好权限控制就行。所以方案一比较好。

[luckyrayyy]

授予上传凭证这个，发给前端又暴露风险吗？

[GM]

@luckyrayyy 没有风险问题。这种凭证都是一次性的，上传之前，中台申请一个凭证，发给前端，前端使用凭证直接上传到 Blob，上传完后，凭证马上失效。

[GM]

@luckyrayyy 而且，中台申请凭证的时候，还可以指定文件 key （也就是说能且仅能上传到指定位置）、限制文件大小、限制文件类型等等。

[DeepDarkVan]

大佬们,目前两种都要支持,第二种主要是给运维人员使用的.老板一直跟我强调并发问题,有点难受,我这边思考这种需要实时知道请求结果的,就不能做异步.第一种方案的话,还有优化空间嘛,毕竟还需要插入数据库做记录,一些其他的校验业务

[106npo]

文件上传的并发问题是啥？

[DeepDarkVan]

@xmumiffy 意思就是请求量大了,大批量请求上传文件,我寻思这个加服务器就行了啊,但是还是要问一下还有优化空间嘛

[Mitt]

没有并发问题，一个请求对应一个处理，也不存在同一个文件同一个位置多次上传，那就按普通处理就完事了，作为中转服务器不需要考虑那么多，压力在存储服务器

[abersheeran]

@DeepDarkVan 第二种并发问题的话，接受文件的接口直接改成微软那个同构的，然后你这边做一个无情的转发机器，用 sendfile 这个系统函数就可以了。对于大文件来说有奇效。

[catror]

运维人员能有几个，根本不存在啥并发问题

[106npo]

@DeepDarkVan 客户端直传微软，你还担心把微软压垮不成

[securityCoding]

方案 1
1.服务端签名
2.客户端直传

[xcstream]

当然是直传了
自己服务器带宽总是有限的