这是一个创建于 1747 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前老板又给了我个私活,写一个文件传输的中台,文件存储服务对接的是微软的 Blob.目前流程是:1.由中台接收前台的上传请求校验后授予上传凭证,前台通过上传凭证直接上传文件到微软的 Blob,然后再通知中台上传成功. 2.由前台直接上传文件到中台,中台再上传到微软 Blob. 大佬们,这系统设计针对大批量请求可以异步处理嘛
 | 1 w504391883 2021-01-05 10:59:49 +08:00 感觉方案一更加合理一些，而且中台不是很需要考虑并发得问题，方案一并发上来得话只要解决请求凭证问题就可以了，瓶颈在 Blob，不在中台 |
 | 2 oxromantic 2021-01-05 11:05:53 +08:00 肯定方案一啊，方案一客户端传成功了就铁定成功了，方案二你还得做和 blob 的异常处理流程，客户端传了个 100%还得等你和 blob 的交互完成 |
 | 3 fengpan567 2021-01-05 11:13:13 +08:00 方案 1 省事 |
 | 4 jswh 2021-01-05 11:25:34 +08:00 文件上传问题在于并发时候的带宽，所以有服务商了实际的上传肯定是丢给服务商的服务器了，自己做好权限控制就行。所以方案一比较好。 |
 | 5 luckyrayyy 2021-01-05 11:28:18 +08:00 授予上传凭证这个，发给前端又暴露风险吗？ |
 | 6 GM 2021-01-05 11:33:02 +08:00 @luckyrayyy 没有风险问题。这种凭证都是一次性的，上传之前，中台申请一个凭证，发给前端，前端使用凭证直接上传到 Blob，上传完后，凭证马上失效。 |
| 7 GM 2021-01-05 11:35:02 +08:00 @luckyrayyy 而且，中台申请凭证的时候，还可以指定文件 key （也就是说能且仅能上传到指定位置）、限制文件大小、限制文件类型等等。 |
 | 8 DeepDarkVan OP 大佬们,目前两种都要支持,第二种主要是给运维人员使用的.老板一直跟我强调并发问题,有点难受,我这边思考这种需要实时知道请求结果的,就不能做异步.第一种方案的话,还有优化空间嘛,毕竟还需要插入数据库做记录,一些其他的校验业务 |
 | 9 106npo 2021-01-05 12:24:05 +08:00 via Android 文件上传的并发问题是啥？ |
| 10 DeepDarkVan OP @xmumiffy 意思就是请求量大了,大批量请求上传文件,我寻思这个加服务器就行了啊,但是还是要问一下还有优化空间嘛 |
 | 11 Mitt 2021-01-05 13:11:08 +08:00 没有并发问题，一个请求对应一个处理，也不存在同一个文件同一个位置多次上传，那就按普通处理就完事了，作为中转服务器不需要考虑那么多，压力在存储服务器 |
 | 12 abersheeran 2021-01-05 13:12:28 +08:00 @DeepDarkVan 第二种并发问题的话，接受文件的接口直接改成微软那个同构的，然后你这边做一个无情的转发机器，用 sendfile 这个系统函数就可以了。对于大文件来说有奇效。 |
 | 13 catror 2021-01-05 13:13:29 +08:00 via Android 运维人员能有几个，根本不存在啥并发问题 |
| 14 106npo 2021-01-05 14:49:35 +08:00 via Android @DeepDarkVan 客户端直传微软，你还担心把微软压垮不成 |
 | 15 securityCoding 2021-01-05 14:52:39 +08:00 方案 1 1.服务端签名 2.客户端直传 |
 | 16 xcstream 2021-01-05 14:54:57 +08:00 当然是直传了 自己服务器带宽总是有限的 |
Select Language