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

集思广益,上司提了个需求要短时间可以扛住 200 万 req/s

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

    先说下背景,跨境电商,主要是 tiktok 直播带货,我们是下游平台,平台技术架构是用 aws serverless lambda, api gateway 和 dynamodb

    一开始 aws 是给了 3000 的 concurrency quota, 后来业务爆发性增长,年中时我们向 aws 申请加到了 5 万 lambda 并发数,本来以为应该可以应付一切了,但上星期日志出现了大量 500 internal server error, 原来是达到 5 万+了,我们问了下 aws 技术支持,说我们当天的峰值到达了 12 万+ req/s

    导致大量商家无法创建下游订单, 大老板直接提了个要求是不允许再发生这种情况, 要求要扛住至少 200 万 请求

    Api gateway 和 dynamodb 是没性应限制的,主要是 lambda 并发数提不上去, aws 那边说最多只能把 lambda 最大并发只能提到 100k

    第 1 条附言  ·  184 天前
    Aws Lambda 并发数限制是 每个帐号算
    第 2 条附言  ·  183 天前
    后续更新,根据 v 友的建议,我们排查了一整天,发现当天实际有效请求刚好是突破了 4 万多,

    这 4 万多请求是来自依赖我们底层支持的第三方调用 都是有效请求, lambda A 是直接面向本次高并发的唯一 lambda ,

    同一时间,由于我们在 aws 控制台,设置了这个 lambda A 只能最多用 45000 个並發执行实例, 其他 5000 是供其他 lambda 调用,这导致在 45001 之后的请求出现 429 too many requests, api gateway 返回了 500 (暂时不知道什麼原因,aws 在排查)给上游,某上游不知道为什么无限异步 retry, 由于该上游的 IP 段在白名单列表, 我们没有在 api gateway 层对这个 IP 设置 rate limit, 导致 api gateway 把所有来自他请求转发到 lambda , 即使后来我们在某次 retry 返回了 201 , 还是没有停, 把後續所有請求都堵死了
    第 3 条附言  ·  183 天前
    那些在这阴阳怪气的人是不时有病,直接出去吧,我没拿枪逼你在这讨论,直接出去不送
    159 条回复    2023-12-15 18:51:34 +08:00
    1  2  
    salmon5
        1
    salmon5  
       184 天前
    真嘟假嘟
    kuituosi
        2
    kuituosi  
       184 天前
    12 万+ req/s 这个量级不是正常流量了,考虑恶意攻击问题
    privil
        3
    privil  
       184 天前
    200 万 req/s 那得多赚钱
    leaflxh
        4
    leaflxh  
       184 天前
    拉到消息队列里缓存一下(个人想法
    coderxy
        5
    coderxy  
       184 天前   ❤️ 12
    真的假的哦? 12w 请求每秒,如果真的都是正常下单,那你们订单量岂不是爆炸? 那还不赶紧扩大团队,高薪聘请大牛,重构后端架构?
    unnamedhao
        6
    unnamedhao  
       184 天前   ❤️ 3
    要不是看到这个问题去查了一下,我还真不相信 lambda 这种类型的服务器有最高并发限制。。。。
    你可以询问一下 aws ,并发最高限制是针对函数的还是针对账户的
    如果是针对函数的可以多创建几个函数,随机访问其中一个
    另外根据文档,如果并发到了限制根据文档返回的应该是 429 而不是 500
    最好再确认一下 500 的原因
    zealotxxxx
        7
    zealotxxxx  
       184 天前   ❤️ 2
    12 的 QPS 基本上是健康码强度的了。但是你们业务不可能有这么多请求,建议还是检察业务,看看是不是被攻击了。
    o562dsRcFqYl375i
        8
    o562dsRcFqYl375i  
       184 天前
    Lambda 不行就把它换了呗,AWS 上的计算服务又不是只有它一个,大把可以无限堆机器扩容的计算产品
    x86
        9
    x86  
       184 天前
    钱到位没有扛不住的量,问问老板钱呢
    wqhui
        10
    wqhui  
       184 天前   ❤️ 1
    200w/s 好吓人,春运抢票也没这么夸张吧
    opengps
        11
    opengps  
       184 天前
    提高并发无非就是分散压力,增加后端支撑
    doanything
        12
    doanything  
       184 天前   ❤️ 1
    12W QPS 。。这么牛逼。考虑用户量与请求量成不成正比先。如果正常的话,那得多赚钱呀。。😕
    hsymlg
        13
    hsymlg  
       184 天前
    这个 qps 有点逆天啊,我盲猜是最底层服务,然后没有设计好业务逻辑和拆分规则,请求放大被上游服务狂调,这种就是自己业务的事情;或者被攻击了,这个既然已经在 aws 上了,基本的异常流量监控应该有的吧,排查一下喽
    biubiuF
        14
    biubiuF  
       184 天前
    用 sqs 延时队列触发 lambda ,设置好节拍避免启动过多实例。另外 dynamodb 有读写性能限制。
    不过这个数据量还是别用 lambda 了
    kanepan19
        15
    kanepan19  
       184 天前   ❤️ 1
    12w ? 这么大的量,已经是赚发了。
    换架构,招架构师
    ETiV
        16
    ETiV  
       184 天前 via iPhone
    如果怀疑是攻击的话,可以前面先套个 WAF
    lsk569937453
        17
    lsk569937453  
       184 天前   ❤️ 1
    1 秒 200 万请求,假设 lambda 并发 100k,则每个 lambda 在 1 秒内需要处理 20 个请求,平均每个请求的相应时间不超过 50ms 。

    理论上 lambda 和后端机器一样,是无状态的,所以可以任意扩展。

    你 1 秒 200 万的请求,真正的瓶颈在后端数据库/缓存。这些有状态的才是你们系统的瓶颈。
    keshawnvan
        18
    keshawnvan  
       184 天前   ❤️ 2
    12 万 QPS 已经接近天猫双十一的量了。
    echoZero
        19
    echoZero  
       184 天前   ❤️ 21
    200 万 req/s ,12306 都得来找你们做。
    lbp0200
        20
    lbp0200  
       184 天前
    试试 Amazon EC2 Auto Scaling ,这个只有流量的限制,直播时开启 128 台机器,平时维持 3 台
    Lax
        21
    Lax  
       184 天前
    下游无限制重试造成的吧。类似的东西,当年抢票插件把 12306 和 github 同时干趴下了。
    tkHello
        22
    tkHello  
       184 天前
    换人?哈哈哈
    tkHello
        23
    tkHello  
       184 天前
    我这有码,大家集思广益都 v 我 50 。
    likunyan
        24
    likunyan  
       184 天前
    @ETiV 200 万,不是 5 万,WAF 不行吧,至少得 6 万一个月的 DDOS 防护。
    hancai
        25
    hancai  
       184 天前
    客户要求达到 2000 ,我们公司都头大
    coderzhangsan
        26
    coderzhangsan  
       184 天前
    订单业务,200 万 QPS ,你知道这意味着什么吗?对应的 TPS ,你们现有架构能撑住?可以考虑下有没有灌水或攻击吧,之前我司接快手广告投放引流(注册转化),非高峰期快手一小时回传了 30 万多有效广告点击数,实际注册转化数 58 。
    zebedy
        27
    zebedy  
       184 天前 via iPhone
    1:你们峰值 12wqps 的流量很多都不是真实流量
    2:你不知道能扛住 200w qps 意味着什么
    Perry
        28
    Perry  
       184 天前
    先看看是不是 retry storm 吧
    thinkm
        29
    thinkm  
       184 天前
    被攻击了
    SmiteChow
        30
    SmiteChow  
       184 天前
    我们一般说要优化 C10k ,你这上来就是 C2000k 啊
    pkoukk
        31
    pkoukk  
       184 天前
    200w?一粒一粒地卖沙子么.....
    dusu
        32
    dusu  
       184 天前 via iPhone
    是否包含所有资源请求 像图片/css/js
    三方电商有 200w 纯 api 的请求
    我也不太信
    如果有 请剔除后再来确定你需要达到的上限
    lovelylain
        33
    lovelylain  
       184 天前 via Android
    雪崩了吧,你对于 12w/s 的请求量有多少认识,服务不是无限堆资源来多少处理多少的,建议先梳理业务实际请求量,各个环节的重试和防过载策略是否合理。
    zjsxwc
        34
    zjsxwc  
       184 天前
    200 万 req/s 你带宽都要逆天了
    Hyschtaxjh
        35
    Hyschtaxjh  
       184 天前
    老板发财了 这么大的量 做梦都笑醒
    zjsxwc
        36
    zjsxwc  
       184 天前
    @zjsxwc 按每个请求 2k 算
    你需要 2000000 * 2 /1024/1024 * 8 = 30.518 约等于 32Gbps 的带宽。
    32Gbps 的带宽 什么概念?

    相当于 PCIe 3.0 x 4 ,最大理论速度,你这是网速,又不是读取 nvme 固体硬盘。
    BaffinLee
        37
    BaffinLee  
       184 天前
    lambda 的限制是整个 aws 的限制还是你这个账号的限制?新建一个账号呢
    murmur
        38
    murmur  
       184 天前
    阿里的交易有效性才是 20w 交易每秒,你们 200w/s 你以为你是阿里全宇通么,先买高防吧,大概率是被黑产或者 d 了
    Weedy152
        39
    Weedy152  
       184 天前
    有点吓人了这个量,mark 一个看看各位大佬解法
    sankooc
        40
    sankooc  
       184 天前
    电商业务 12w 的 qps 几乎接近双 11 了
    zzNucker
        41
    zzNucker  
       184 天前
    你们技术团队没有先分析一下需求的合理性吗?
    diagnostics
        42
    diagnostics  
       184 天前
    @coderzhangsan CPC 和 CPR 还是不一样的,你看到广告就会注册吗?有效点击大概率是误触,当然也不乏快手有作弊嫌疑
    coderzhangsan
        43
    coderzhangsan  
       184 天前
    @diagnostics 不可能是误触,开启广告投放的时间点属于低谷期,直播间人数高峰期也不过百人,还需要用户点击直播间风车组件,点击后会直接引流到应用市场,所以这几十万条有效点击数明显是灌水数据。
    Pythoner666666
        44
    Pythoner666666  
       184 天前
    12 万 QPS ,如果是下单的接口,那不赚发了
    justfindu
        45
    justfindu  
       184 天前
    超出了我的能力认知范围. 不知道 12306 和 淘宝 这些能不能搞到
    dko
        46
    dko  
       184 天前
    考虑下分流+多活?
    wheat0r
        47
    wheat0r  
       184 天前   ❤️ 1
    200 万 req/s
    莫非 lambda 这些产品是贵公司自家的产品?
    herozzm
        48
    herozzm  
       184 天前
    被攻击了,还傻乎乎的提升 qrs
    justfindu
        49
    justfindu  
       184 天前
    首先考虑已经上了这么多 req 之后 , 业务增长有多少? 就能分辨出来是否正常了.
    zzNucker
        50
    zzNucker  
       184 天前
    @justfindu 200w 估计都超过天猫双十一峰值购物车 QPS 了
    diveIntoWork
        51
    diveIntoWork  
       184 天前
    200 万 qps ,比 tiktok 还牛
    owen800q
        52
    owen800q  
    OP
       184 天前 via iPhone
    @dko 分流的前提是最外层得有个东西可以接住 12 万+ 请求吧,然後再做分流?
    tairan2006
        53
    tairan2006  
       184 天前
    12w 已经够离谱了。。这不财务自由了
    owen800q
        54
    owen800q  
    OP
       184 天前 via iPhone
    12w + 全是 API 调用。没有 html js css 那些,不全是下单请求,还有运费查询和商品详情
    @sankooc
    @murmur
    @Hyschtaxjh
    @dusu
    salmon5
        55
    salmon5  
       184 天前
    我感觉你这是面试题,套方案
    cnbatch
        56
    cnbatch  
       184 天前
    第一反应,应该是被盯上受到攻击了吧

    就算做到了扛住 200 万,攻击者可以继续加码弄到 300 万、400 万。

    所以对于“大老板”的要求,不如索性往这个方向调查,让大老板知道是你们被人盯上、遭到了攻击,哪怕弄到能抗住 1 千万请求都是徒劳,正确做法恐怕是使用流量清洗服务。
    tqyq88
        57
    tqyq88  
       184 天前   ❤️ 1
    简化方案,随机 drop 99%就行了
    owen800q
        58
    owen800q  
    OP
       184 天前 via iPhone
    @hsymlg 是的,主要是底层支撑
    salmon5
        59
    salmon5  
       184 天前
    这个业务规模,研发至少数千人规模,还有时间来 v2 问?
    zzNucker
        60
    zzNucker  
       184 天前
    拆分一下你们的服务,不要全放一个集群
    swulling
        61
    swulling  
       184 天前
    这个规模的请求量,不可能都是交易请求。根据#54 可以看到有很多是非交易请求。且先假设都是真实流量。

    限制你的只是 AWS Lambda 的技术限制而已,这就是 Vendor Lock ,当你的用量超过了云服务商的能力,你无能为力。

    解决办法也很简单,就是拆分。把你的部分服务从 Lambda 拆分到 EC2 虚拟机上就完了。
    matrix1010
        62
    matrix1010  
       184 天前 via iPhone
    看上去 google cloud function 可以无限扩展 https://cloud.google.com/functions/docs/configuring/max-instances?hl=zh-cn
    whileFalse
        63
    whileFalse  
       184 天前 via Android
    套 waf 清洗流量。
    你们这么大流量 可以考虑改用 ec2/ecs 之类的架构了。
    bitmin
        64
    bitmin  
       184 天前
    @owen800q #52 分流的前提是最外层得有个东西可以接住 12 万+ 请求吧,然後再做分流?


    萌新说个想法,不需要最外层有东西接住 12 万+ 请求

    一种是不同 API 域名解析指向不同的服务

    另一种更进一步,分发给不同调用方的相同 API 配置不同地址解析到不同的服务

    在源头就分流了
    XSDo
        65
    XSDo  
       184 天前
    假设 12W 并发都是真实的,12W 并发之后瓶颈在什么地方?数据库 IO ,网络 IO ,业务逻辑计算耗时?

    先定位到瓶颈在什么地方才好做,如果都没有瓶颈,无状态服务,直接无脑横向扩展服务。
    dko
        66
    dko  
       184 天前
    @owen800q #52 是的,一般都用 API 网关来解决,同时 API 网关也会补多套来做 LB 及调度,可以这样简单的理解:不同区域的流量进不同机房,但是这种需要拆分某些单节点的情况。
    看起来你们的流量只是瞬时,并且对数据同步的要求并不是特别的高,那用分流这种方案还是比较适合的。
    bthulu
        67
    bthulu  
       184 天前
    @lbp0200 不是 128 台, 是得开 128 万台
    v2orz
        68
    v2orz  
       184 天前
    12w qps 最外层负载均衡能接的吧,LVS+Haproxy 。
    不行就终极方法上 F5 ,我这里的 12w 就是这么接下来的
    @owen800q
    v2orz
        69
    v2orz  
       184 天前
    额,漏了 200 万,200 万单入口感觉撑不下,从 dns 方面估计要想想办法,分线路分区域解析,然后再分接口
    salmon5
        70
    salmon5  
       184 天前
    我比较关心,你们 AWS 消费大概什么级别?¥ 9 位数/年 有了吧
    GeekGao
        71
    GeekGao  
       183 天前
    你们 GMV 难道几百亿吗? 先排查是不是被攻击了
    ChadGPT
        72
    ChadGPT  
       183 天前
    mark 一下,围观大佬回答
    shellcodecow
        73
    shellcodecow  
       183 天前
    对着老板说,抬起右手,伸出中指 ,大声喊:你来做! 200w req/s ? 你来做做看
    Huelse
        74
    Huelse  
       183 天前
    这个量级没有业务问题直接加机器吧,没什么更有效的方法了
    sumarker
        75
    sumarker  
       183 天前
    既然是下游业务平台 ,200w 的 qps 完全可以做业务拆分自己维护,而不是托管在 serverless 上,然后上一套削峰限流异步处理 防止直接打到机器上……
    zouywx86
        76
    zouywx86  
       183 天前
    12W 请求峰值,我感觉这个有 2 方面是可以考虑去排查下的:
    1 、被攻击了;做电商被攻击太正常的,不知道是否做了这方面的处理;
    2 、系统层面有无脑疯狂重试的代码;就是其中一个接口爆了之后,引发的系统级崩溃,然后有请求不断做重试,最终累积了 12w 最高请求的峰值;

    至于你们老板要求的 200w 支持能力,在他的角度来说,还不算疯狂,听听就好。我当年面上过一个初创企业( 16 年),面试官上来就说我们的系统是做广告业的,要随时做好上亿请求的准备,我投去了很敬佩的目光,不知道现在他们的人数超过 10 个了没。
    enihcam
        77
    enihcam  
       183 天前
    套面试题的?
    Hider5
        78
    Hider5  
       183 天前
    关注下,我司一小时 4w 单,下单最高 tps 也就 200,12w 这得多少单啊
    codersdp1
        79
    codersdp1  
       183 天前
    @enihcam 面试也不会造这么大的火箭
    codersdp1
        80
    codersdp1  
       183 天前
    查看过往历史监控~是不是如果只是最近流量指数暴涨,那肯定是被攻击了。
    xuanbg
        81
    xuanbg  
       183 天前
    120 的 qps 就相当猛了,1 秒钟时间,有 120 次接口调用,那得有几千甚至上万的在线用户才能有这么高的 qps 。

    看到 12 万 qps 的时候,第一反应应该是是不是被攻击了而不是去想办法提升 qps
    ukpkmk
        82
    ukpkmk  
       183 天前
    12306 都没有你们牛逼
    ukpkmk
        83
    ukpkmk  
       183 天前
    太狠了
    feiniu
        84
    feiniu  
       183 天前
    🐂🍺
    Mithril
        85
    Mithril  
       183 天前
    这么大的访问量还要用 lambda 吗。。。
    你们这账单老板也觉得能接受?
    go522000
        86
    go522000  
       183 天前
    这个量有点大,我猜测是上游卖家在实时查询所有货的库存量?比如系统 1 秒查询一次,一次查询 N 个商品,而且这 N 个商品还分开为 N 个请求同时过来?
    猜测的。
    建议 OP 把架构放出来比较好给出建议。
    JKeita
        87
    JKeita  
       183 天前
    确定不是被人攻击了?
    ddkk1112
        88
    ddkk1112  
       183 天前
    200 万并发?地球上有这样的应用场景
    ymy3232
        89
    ymy3232  
       183 天前
    我们的 api 接口高峰时段大概 3.5w req/s rt 平均 600ms 用了一个 LB 加 10 个 4c8g 的 ECS 感觉绰绰有余, 核心服务在架构的时候只依赖 redis ,去除了一切对 rt 有影响的中间件都改用 redis 实现,对于我们来说加到 20w req/s 也只是加机器的问题,但是 200w 也不太敢想
    ymy3232
        90
    ymy3232  
       183 天前
    @zouywx86 广告系统百亿请求都很普遍
    ShaoLongFei
        91
    ShaoLongFei  
       183 天前
    ec2 + auto scaling ,wlb + sqs
    RipL
        92
    RipL  
       183 天前
    下单 12w+ 快赶上淘宝的双十一了吧 200w 比淘宝双十一都要牛逼了
    burymme11
        93
    burymme11  
       183 天前
    萌新 蹲一个后续。
    4771314
        94
    4771314  
       183 天前
    12w 的下单 qps ,我的乖乖,赚大发了啊,快去把阿里淘宝的总架构师挖过来
    hefish
        95
    hefish  
       183 天前
    走,先找 dell 买服务器去,啊不对,买回来没地方堆。。
    找当地政府要块地,先建机房。。。咳咳。。。
    wenjie83
        96
    wenjie83  
       183 天前
    @wqhui 不好说,有大量垃圾的抢票软件
    8355
        97
    8355  
       183 天前
    那不是说明不应该用 Lambda 吗。。。 你们这个架构做的啥玩意啊。。
    j519
        98
    j519  
       183 天前
    你老板没那个实力拿(赚)那么多钱干什么?
    shenjinpeng
        99
    shenjinpeng  
       183 天前
    淘宝都没你牛
    wqhui
        100
    wqhui  
       183 天前
    我觉得思路是尽早拦截过滤无效请求、合并小请求、按地域把流量划分到不同机房
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2733 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 07:22 · PVG 15:22 · LAX 00:22 · JFK 03:22
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.