这是一个创建于 1452 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前老板又给了我个私活,写一个文件传输的中台,文件存储服务对接的是微软的 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
xmumiffy 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
xmumiffy 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