• 请不要在回答技术问题时复制粘贴 AI 生成的内容
owen800q
V2EX  ›  程序员

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

  •  
  •   owen800q · Dec 14, 2023 via iPhone · 29787 views
    This topic created in 1055 days ago, the information mentioned may be changed or developed.

    先说下背景,跨境电商,主要是 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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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