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

• 資深大佬 : w504391883

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

• 資深大佬 : oxromantic

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

• 資深大佬 : fengpan567

  方案 1 省事

• 資深大佬 : jswh

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

• 資深大佬 : luckyrayyy

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

• 資深大佬 : GM

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

• 資深大佬 : GM

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

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

• 資深大佬 : xmumiffy

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

• 主 資深大佬 : DeepDarkVan

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

• 資深大佬 : Mitt

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

• 資深大佬 : abersheeran

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

• 資深大佬 : catror

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

• 資深大佬 : xmumiffy

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

• 資深大佬 : securityCoding

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

• 資深大佬 : xcstream

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