首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  PHP

PHP 高并发大图片上传怎么架构

  •  
  •   zhengwhizz · 42 天前 · 3200 次点击
    这是一个创建于 42 天前的主题,其中的信息可能已经有所发展或是发生改变。

    有个网站有时会涉及几百号人同时上传 2M 左右的图片好多张,这种情况下经常会丢失图片,怎么处理好呢?

    50 回复  |  直到 2019-05-08 09:38:14 +08:00
        1
    sujin190   42 天前   ♥ 1
    用又拍或者七牛
        2
    HanSonJ   42 天前
    前端上传
        3
    itchihuo   42 天前
    1 楼正解,直接前端上传云存储平台
        4
    tanszhe   42 天前
    关键在带宽
        5
    DefineJ   42 天前
    一定要自己的服务器搞个队列也行
        6
    keepeye   42 天前
    我觉得还是先搞清楚为什么会丢失图片比较好
        7
    googlecomhk   42 天前 via Android
        8
    feiandxs   42 天前
    我觉得这里搞清思路找到问题所在就好,但这个场景下造轮子真的是最没有必要的。。

    1 效果没前端直传第三方好。
    2 造一遍也是各种封装,还涉及 token 鉴权之类的,开发成本高。
    3 你造出来也没人家好,从业务角度来说就不该考虑。
    4 也不用担心第三方平台倒闭之类的。。。带宽足,成本低,一般倒的比别家公司还晚。。。

    就知识可以学学,自己再试图强行搞定高并发下的图片上传,又费钱又费人还学不到啥。。。
        9
    cnbattle   42 天前
    同 1 楼 直接往第三方上面怼
        10
    zhengwhizz   42 天前
    @sujin190
    @itchihuo
    @cnbattle 项目涉及到使用这些图片生成 PDF 还有打包下载,很多地方用到这些图片,怼云存储要调整好多地方,甲方不加资金没得搞,现在我就想弄清楚,如果在自己服怎么搞能避免丢失
        11
    zhengwhizz   42 天前
    @keepeye 丢图应该就是处理不过来挂了,反正很怪异,没任何规律,重名也不可能,重名覆盖的话数据库有记录至少会破图,上传的时候 3-4 天有 40G 的量,时间点上来说还相对集中。
        12
    plqws   42 天前
    几百人同时上传 2M 的图片并不是什么大压力的场景啊,难道不是代码逻辑有问题吗
        13
    zhengwhizz   42 天前
    @plqws 问题服务器只有 4M 带宽,并且上传的时候每个人都是一批的传,同时有对图片生成缩略图的操作,并且有些还有水印操作,也就是每个人估算会传十几二十张甚至更多,虽然并发时不一定有几百人,从以往的数据量来看,3 天左右 40G 的量,时间也相对集中。
        14
    zhengwhizz   42 天前
    @plqws 有没有什么方法检测到当时的并发量?或者图片上传请求量?
        15
    ouou8   42 天前
    @zhengwhizz 暂时没有办法解决的情况下,你先限制一下每人一次只能上传图片的数量,比如一次最多只能上传 20 张,甚至更少一些。
        16
    mamahaha   42 天前
    你介四传的太慢超时了啊,ini 里可以调节一下,要想可靠就做队列或断点续传,断点续传的工具很多的一搜一堆。
        17
    server   42 天前
    临时授权,不过低版本 ie 不行, https://help.aliyun.com/document_detail/31953.html
        18
    zhengwhizz   42 天前
    @mamahaha 接收代码里直接设置 0 的,
        19
    zhengwhizz   42 天前
    @ouou8 客户不让限,而且也不让压,本来可以客户端压一下,但是客户看图片质量就看 KB 数。
        20
    dobelee   42 天前 via Android   ♥ 2
    几百个人同时上传 2m 图片,带宽只有 4m。
    这个背景下讨论架构有意义?
        21
    shiny   42 天前
    云服务器流入的带宽不是没什么限制吗
        22
    opengps   42 天前
    如果是阿里云的话:
    正常使用服务器的带宽上传,然后服务器内网传输给 OSS,然后引用地址返回 OSS 的公网地址。参考我的博客最后两段 https://www.opengps.cn/Blog/View.aspx?id=43&from=v2
        23
    king2014   42 天前
    10M 的带宽 8 核 16g 的机子,7 天有 3000 个人上传手机照片(手机照片不小 7,8M 有的),整个活动下来没有出现问题,可能并发没有我想的那么高的缘故吧
        24
    emeab   42 天前
    带宽问题吧. 4m 水管单传一个 2m 的图片都要 2 秒了 更别说同时了
        25
    king2014   42 天前
    每个人估算会传十几二十张甚至更多,每张图片 2M。。。这还怎么搞?
    相当于一个人就要上传 20M-40M 的图片,再来个 100 并发岂不是瞬间上传 2G-4G 的图片,几百号人岂不是更多。。。
        26
    veike   42 天前
    @emeab 上传时间要看文件大小单位,服务器 4M 是 bit,文件是 byte,所以 2s 传不完。
        27
    opengps   42 天前
    22 楼补充:
    对于传统机房的对等带宽,除了加带宽没别的办法。
    对于国内各种云,带宽几乎全是只限制服务器出方向大小(入方向一般是 100M 或 200M 并且免费)。对象存储都是按流量收费,峰值带宽往往是 100M 起步
    所以,这个问题可以用内网可打通的云服务器和对象存储搭配解决
        28
    veike   42 天前
    @opengps 上行真的有那么大吗?
        29
    yc8332   42 天前
    第三方存储服务搞起来。。。
        30
    KasuganoSoras   42 天前
    你要是只有 4M 宽带,就算你把程序优化成神仙也没用,速度还是只有 4M,就那个样
    解决方法就是加宽带,或者用第三方储存服务
        31
    opengps   42 天前
    @veike 阿里云官网给出解释:按量付费的带宽上限是 100M,按固定带宽付费的上限是 200M
        33
    opengps   42 天前
    新找的图床好像不太好用,倒数第二个图片链接是官网文档截图
        34
    zhengwhizz   42 天前
    @opengps 你是说上传图片的时候带宽并不是 4M?? 而是 100-200M ?只是访问的时候是 4M ?
        35
    opengps   42 天前
    @zhengwhizz 是的。注意前提条件是:你用的是云服务器这种“非对等”带宽
        36
    zhengwhizz   42 天前
    @opengps 用的就是阿里,我也看了阿里的说明,这么说的话上传的瓶颈其实就是用户端这边了,但是这边只有他一人在传,假如同一时间有 10 个人在传,每人 6M,服务器处理 60M 的图片进行压缩 /打水印,是服务器运力不够了?服务器好像是 4 核 8G。
        37
    opengps   42 天前   ♥ 1
    @zhengwhizz 你好像没 get 到我的点,我不是说你上传不够。
    我是说你的上传之后的引用加载,占用了服务器的 4M 带宽,导致交互通讯时候有一个方向受阻了,可能在这个地方导致的其他人失败(上传过程也会需要一点下载流量的)
        38
    jugelizi   42 天前
    怎么看上去就是发包攻击了
        39
    mumbler   42 天前
    阿里云的 ECS 和 OSS 上行数据都是免费的,最高 1G 带宽,4M 只是下行带宽而已.
        40
    z5864703   42 天前
    应该就是像 37 楼所说,上传没问题,只是因为页面展示图片的时候把 4M 的出网带宽占满导致别的入网请求交互握手阻塞。
    如果是这种,可以考虑把页面展示的使用缩略图,压缩出网带宽开销
        41
    emeab   42 天前
    @z5864703 再怎么压缩 并发那么高的话 4m 怎么够
        42
    akira   42 天前
    直传 3 方存储 是最好的方案了
        43
    zhengwhizz   42 天前
    @opengps 了解了,应该就是这原因了
        44
    zjsxwc   42 天前 via Android
    七牛或别的 提供 token 前端上传
        45
    liuyang3688   42 天前
    同意 37 楼和 40 楼 通过服务器端验证下 就知道有没有上传成功。如果确实是上传成功后 拉取图片显示的问题 那么服务端生成缩略图可解 但是高并发下 即便是缩略图 也要考虑你的 4m 带宽

    上云 引用地址最靠谱
        46
    lscho   42 天前
    4m 带宽谈什么架构。。。。
        47
    luozic   42 天前
    4m 出口 還要上傳圖片? 哈哈哈哈哈哈哈哈哈
        48
    fuxkcsdn   42 天前 via iPhone
    如果上传带宽没问题,那就上队列,4 核 8G 应对这个量足够了
    web 只负责接收图片并把图片移动到指定目录,然后任务入列,之后由队列处理后续事宜
        49
    qbhy   42 天前
    前端上传到云存储就行了,php 生成个 token 就好,压力不大
        50
    opengps   42 天前 via Android
    前端上传有风险,你自己能上传的同时别人也能上传,慎用!
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4058 人在线   最高记录 5043   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 21ms · UTC 02:38 · PVG 10:38 · LAX 19:38 · JFK 22:38
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1