这是一个创建于 667 天前的主题，其中的信息可能已经有所发展或是发生改变。
先说下背景，跨境电商，主要是 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 条附言 2023-12-14 14:02:33 +08:00
Aws Lambda 并发数限制是 每个帐号算
第 2 条附言 2023-12-14 20:21:13 +08:00
后续更新，根据 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 ， 还是没有停, 把後所有求都堵死了
这 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 条附言 2023-12-15 10:08:48 +08:00
那些在这阴阳怪气的人是不时有病，直接出去吧，我没拿枪逼你在这讨论，直接出去不送
 | 1 salmon5 2023-12-14 10:41:52 +08:00 真嘟假嘟 |
 | 2 kuituosi 2023-12-14 10:42:23 +08:00 12 万+ req/s 这个量级不是正常流量了，考虑恶意攻击问题 |
 | 3 privil 2023-12-14 10:43:02 +08:00 200 万 req/s 那得多赚钱 |
 | 4 leaflxh 2023-12-14 10:43:41 +08:00 拉到消息队列里缓存一下（个人想法 |
 | 5 coderxy 2023-12-14 10:44:12 +08:00  12 真的假的哦？ 12w 请求每秒，如果真的都是正常下单，那你们订单量岂不是爆炸？ 那还不赶紧扩大团队，高薪聘请大牛，重构后端架构？ |
 | 6 unnamedhao 2023-12-14 10:45:44 +08:00 3 要不是看到这个问题去查了一下，我还真不相信 lambda 这种类型的服务器有最高并发限制。。。。 你可以询问一下 aws ，并发最高限制是针对函数的还是针对账户的 如果是针对函数的可以多创建几个函数，随机访问其中一个 另外根据文档，如果并发到了限制根据文档返回的应该是 429 而不是 500 最好再确认一下 500 的原因 |
 | 7 zealotxxxx 2023-12-14 10:46:54 +08:00 2 12 的 QPS 基本上是健康码强度的了。但是你们业务不可能有这么多请求，建议还是检察业务，看看是不是被攻击了。 |
 | 8 o562dsRcFqYl375i 2023-12-14 10:48:49 +08:00 Lambda 不行就把它换了呗，AWS 上的计算服务又不是只有它一个，大把可以无限堆机器扩容的计算产品 |
 | 9 x86 2023-12-14 10:49:39 +08:00 钱到位没有扛不住的量,问问老板钱呢 |
 | 10 wqhui 2023-12-14 10:51:28 +08:00 1 200w/s 好吓人，春运抢票也没这么夸张吧 |
 | 11 opengps 2023-12-14 10:56:32 +08:00 提高并发无非就是分散压力，增加后端支撑 |
 | 12 doanything 2023-12-14 10:57:15 +08:00 1 12W QPS 。。这么牛逼。考虑用户量与请求量成不成正比先。如果正常的话，那得多赚钱呀。。 |
 | 13 hsymlg 2023-12-14 10:58:03 +08:00 这个 qps 有点逆天啊，我盲猜是最底层服务，然后没有设计好业务逻辑和拆分规则，请求放大被上游服务狂调，这种就是自己业务的事情；或者被攻击了，这个既然已经在 aws 上了，基本的异常流量监控应该有的吧，排查一下喽 |
 | 14 biubiuF 2023-12-14 11:00:47 +08:00 用 sqs 延时队列触发 lambda ，设置好节拍避免启动过多实例。另外 dynamodb 有读写性能限制。 不过这个数据量还是别用 lambda 了 |
 | 15 kanepan19 2023-12-14 11:01:39 +08:00 1 12w ？ 这么大的量，已经是赚发了。 换架构，招架构师 |
 | 16 ETiV 2023-12-14 11:02:36 +08:00 via iPhone 如果怀疑是攻击的话，可以前面先套个 WAF |
 | 17 lsk569937453 2023-12-14 11:04:21 +08:00 1 1 秒 200 万请求，假设 lambda 并发 100k,则每个 lambda 在 1 秒内需要处理 20 个请求，平均每个请求的相应时间不超过 50ms 。 理论上 lambda 和后端机器一样，是无状态的，所以可以任意扩展。 你 1 秒 200 万的请求，真正的瓶颈在后端数据库/缓存。这些有状态的才是你们系统的瓶颈。 |
 | 18 keshawnvan 2023-12-14 11:11:58 +08:00 2 12 万 QPS 已经接近天猫双十一的量了。 |
 | 19 echoZero 2023-12-14 11:16:17 +08:00 21 200 万 req/s ，12306 都得来找你们做。 |
 | 20 lbp0200 2023-12-14 11:19:59 +08:00 试试 Amazon EC2 Auto Scaling ，这个只有流量的限制，直播时开启 128 台机器，平时维持 3 台 |
 | 21 Lax 2023-12-14 11:21:00 +08:00 下游无限制重试造成的吧。类似的东西，当年抢票插件把 12306 和 github 同时干趴下了。 |
 | 22 tkHello 2023-12-14 11:23:28 +08:00 换人？哈哈哈 |
| 23 tkHello 2023-12-14 11:24:14 +08:00 我这有码，大家集思广益都 v 我 50 。 |
 | 24 QKgf555H87Fp0cth 2023-12-14 11:30:26 +08:00 @ETiV 200 万，不是 5 万，WAF 不行吧，至少得 6 万一个月的 DDOS 防护。 |
 | 25 hancai 2023-12-14 11:37:15 +08:00 客户要求达到 2000 ，我们公司都头大 |
 | 26 coderzhangsan 2023-12-14 11:43:20 +08:00 订单业务，200 万 QPS ，你知道这意味着什么吗？对应的 TPS ，你们现有架构能撑住？可以考虑下有没有灌水或攻击吧，之前我司接快手广告投放引流(注册转化)，非高峰期快手一小时回传了 30 万多有效广告点击数，实际注册转化数 58 。 |
 | 27 zebedy 2023-12-14 11:49:20 +08:00 via iPhone 1:你们峰值 12wqps 的流量很多都不是真实流量 2:你不知道能扛住 200w qps 意味着什么 |
 | 28 Perry 2023-12-14 11:49:45 +08:00 先看看是不是 retry storm 吧 |
 | 29 thinkm 2023-12-14 11:50:11 +08:00 被攻击了 |
 | 30 SmiteChow 2023-12-14 11:54:01 +08:00 我们一般说要优化 C10k ，你这上来就是 C2000k 啊 |
 | 31 pkoukk 2023-12-14 11:58:11 +08:00 200w?一粒一粒地卖沙子么..... |
 | 32 dusu 2023-12-14 12:37:53 +08:00 via iPhone 是否包含所有资源请求 像图片/css/js 三方电商有 200w 纯 api 的请求 我也不太信 如果有 请剔除后再来确定你需要达到的上限 |
 | 33 lovelylain 2023-12-14 12:48:28 +08:00 via Android 雪崩了吧，你对于 12w/s 的请求量有多少认识，服务不是无限堆资源来多少处理多少的，建议先梳理业务实际请求量，各个环节的重试和防过载策略是否合理。 |
 | 34 zjsxwc 2023-12-14 12:55:08 +08:00 200 万 req/s 你带宽都要逆天了 |
 | 35 Hyschtaxjh 2023-12-14 12:55:39 +08:00 老板发财了 这么大的量 做梦都笑醒 |
| 36 zjsxwc 2023-12-14 13:00:11 +08:00 @zjsxwc 按每个请求 2k 算 你需要 2000000 * 2 /1024/1024 * 8 = 30.518 约等于 32Gbps 的带宽。 32Gbps 的带宽 什么概念？ 相当于 PCIe 3.0 x 4 ，最大理论速度，你这是网速，又不是读取 nvme 固体硬盘。 |
 | 37 BaffinLee 2023-12-14 13:00:23 +08:00 lambda 的限制是整个 aws 的限制还是你这个账号的限制？新建一个账号呢 |
 | 38 murmur 2023-12-14 13:04:25 +08:00 阿里的交易有效性才是 20w 交易每秒，你们 200w/s 你以为你是阿里全宇通么，先买高防吧，大概率是被黑产或者 d 了 |
 | 39 Weedy152 2023-12-14 13:04:58 +08:00 有点吓人了这个量，mark 一个看看各位大佬解法 |
 | 40 sankooc 2023-12-14 13:37:18 +08:00 电商业务 12w 的 qps 几乎接近双 11 了 |
 | 41 zzNucker 2023-12-14 13:39:40 +08:00 你们技术团队没有先分析一下需求的合理性吗？ |
 | 42 diagnostics 2023-12-14 13:39:57 +08:00 @coderzhangsan CPC 和 CPR 还是不一样的，你看到广告就会注册吗？有效点击大概率是误触，当然也不乏快手有作弊嫌疑 |
| 43 coderzhangsan 2023-12-14 13:48:25 +08:00 @diagnostics 不可能是误触，开启广告投放的时间点属于低谷期，直播间人数高峰期也不过百人，还需要用户点击直播间风车组件，点击后会直接引流到应用市场，所以这几十万条有效点击数明显是灌水数据。 |
 | 44 Pythoner666666 2023-12-14 13:49:09 +08:00 12 万 QPS ，如果是下单的接口，那不赚发了 |
 | 45 justfindu 2023-12-14 13:50:29 +08:00 超出了我的能力认知范围. 不知道 12306 和 淘宝 这些能不能搞到 |
 | 46 dko 2023-12-14 13:56:55 +08:00 考虑下分流+多活？ |
 | 47 wheat0r 2023-12-14 13:57:40 +08:00 1 200 万 req/s 莫非 lambda 这些产品是贵公司自家的产品？ |
 | 48 herozzm 2023-12-14 13:57:46 +08:00 被攻击了，还傻乎乎的提升 qrs |
| 49 justfindu 2023-12-14 14:00:02 +08:00 首先考虑已经上了这么多 req 之后 , 业务增长有多少? 就能分辨出来是否正常了. |
 | 51 diveIntoWork 2023-12-14 14:03:51 +08:00 200 万 qps ，比 tiktok 还牛 |
 | 53 tairan2006 2023-12-14 14:08:12 +08:00 12w 已经够离谱了。。这不财务自由了 |
 | 54 owen800q OP |
| 55 salmon5 2023-12-14 14:13:53 +08:00 我感觉你这是面试题，套方案 |
 | 56 cnbatch 2023-12-14 14:14:02 +08:00 第一反应，应该是被盯上受到攻击了吧 就算做到了扛住 200 万，攻击者可以继续加码弄到 300 万、400 万。 所以对于“大老板”的要求，不如索性往这个方向调查，让大老板知道是你们被人盯上、遭到了攻击，哪怕弄到能抗住 1 千万请求都是徒劳，正确做法恐怕是使用流量清洗服务。 |
 | 57 tqyq88 2023-12-14 14:14:38 +08:00 1 简化方案，随机 drop 99%就行了 |
| 59 salmon5 2023-12-14 14:16:06 +08:00 这个业务规模，研发至少数千人规模，还有时间来 v2 问？ |
| 60 zzNucker 2023-12-14 14:16:20 +08:00 拆分一下你们的服务，不要全放一个集群 |
 | 61 swulling 2023-12-14 14:20:13 +08:00 这个规模的请求量，不可能都是交易请求。根据#54 可以看到有很多是非交易请求。且先假设都是真实流量。 限制你的只是 AWS Lambda 的技术限制而已，这就是 Vendor Lock ，当你的用量超过了云服务商的能力，你无能为力。 解决办法也很简单，就是拆分。把你的部分服务从 Lambda 拆分到 EC2 虚拟机上就完了。 |
 | 62 matrix1010 2023-12-14 14:21:42 +08:00 via iPhone 看上去 google cloud function 可以无限扩展 https://cloud.google.com/functions/docs/configuring/max-instances?hl=zh-cn |
 | 63 whileFalse 2023-12-14 14:22:14 +08:00 via Android 套 waf 清洗流量。 你们这么大流量 可以考虑改用 ec2/ecs 之类的架构了。 |
 | 64 bitmin 2023-12-14 14:28:35 +08:00 @owen800q #52 分流的前提是最外层得有个东西可以接住 12 万+ 请求吧，然後再做分流？ 萌新说个想法，不需要最外层有东西接住 12 万+ 请求 一种是不同 API 域名解析指向不同的服务 另一种更进一步，分发给不同调用方的相同 API 配置不同地址解析到不同的服务 在源头就分流了 |
 | 65 XSDo 2023-12-14 14:47:26 +08:00 假设 12W 并发都是真实的，12W 并发之后瓶颈在什么地方？数据库 IO ，网络 IO ，业务逻辑计算耗时？ 先定位到瓶颈在什么地方才好做，如果都没有瓶颈，无状态服务，直接无脑横向扩展服务。 |
| 66 dko 2023-12-14 14:50:06 +08:00 @owen800q #52 是的，一般都用 API 网关来解决，同时 API 网关也会补多套来做 LB 及调度，可以这样简单的理解：不同区域的流量进不同机房，但是这种需要拆分某些单节点的情况。 看起来你们的流量只是瞬时，并且对数据同步的要求并不是特别的高，那用分流这种方案还是比较适合的。 |
 | 68 v2orz 2023-12-14 14:53:24 +08:00 |
| 69 v2orz 2023-12-14 14:56:42 +08:00 额，漏了 200 万，200 万单入口感觉撑不下，从 dns 方面估计要想想办法，分线路分区域解析，然后再分接口 |
| 70 salmon5 2023-12-14 15:15:27 +08:00 我比较关心，你们 AWS 消费大概什么级别？￥ 9 位数/年 有了吧 |
| 71 R4rvZ6agNVWr56V0 2023-12-14 15:26:53 +08:00 你们 GMV 难道几百亿吗？ 先排查是不是被攻击了 |
 | 72 ChadGPT 2023-12-14 15:32:15 +08:00 mark 一下，围观大佬回答 |
 | 73 shellcodecow 2023-12-14 15:32:38 +08:00 对着老板说，抬起右手，伸出中指 ,大声喊：你来做！ 200w req/s ? 你来做做看 |
 | 74 Huelse 2023-12-14 15:36:59 +08:00 这个量级没有业务问题直接加机器吧，没什么更有效的方法了 |
 | 75 sumarker PRO 既然是下游业务平台 ，200w 的 qps 完全可以做业务拆分自己维护，而不是托管在 serverless 上，然后上一套削峰限流异步处理 防止直接打到机器上…… |
 | 76 zouywx86 2023-12-14 15:49:41 +08:00 12W 请求峰值，我感觉这个有 2 方面是可以考虑去排查下的： 1 、被攻击了；做电商被攻击太正常的，不知道是否做了这方面的处理； 2 、系统层面有无脑疯狂重试的代码；就是其中一个接口爆了之后，引发的系统级崩溃，然后有请求不断做重试，最终累积了 12w 最高请求的峰值； 至于你们老板要求的 200w 支持能力，在他的角度来说，还不算疯狂，听听就好。我当年面上过一个初创企业（ 16 年），面试官上来就说我们的系统是做广告业的，要随时做好上亿请求的准备，我投去了很敬佩的目光，不知道现在他们的人数超过 10 个了没。 |
 | 77 enihcam 2023-12-14 15:55:59 +08:00 套面试题的？ |
 | 78 Hider5 2023-12-14 15:59:08 +08:00 关注下，我司一小时 4w 单，下单最高 tps 也就 200,12w 这得多少单啊 |
 | 80 codersdp1 2023-12-14 16:07:38 +08:00 查看过往历史监控～是不是如果只是最近流量指数暴涨，那肯定是被攻击了。 |
 | 81 xuanbg 2023-12-14 16:08:10 +08:00 120 的 qps 就相当猛了，1 秒钟时间，有 120 次接口调用，那得有几千甚至上万的在线用户才能有这么高的 qps 。 看到 12 万 qps 的时候，第一反应应该是是不是被攻击了而不是去想办法提升 qps |
 | 82 5800X3D 2023-12-14 16:23:09 +08:00 12306 都没有你们牛逼 |
| 83 5800X3D 2023-12-14 16:24:56 +08:00 太狠了 |
 | 84 feiniu 2023-12-14 16:37:45 +08:00 |
 | 85 Mithril 2023-12-14 16:49:58 +08:00 这么大的访问量还要用 lambda 吗。。。 你们这账单老板也觉得能接受？ |
 | 86 go522000 2023-12-14 17:02:22 +08:00 这个量有点大，我猜测是上游卖家在实时查询所有货的库存量？比如系统 1 秒查询一次，一次查询 N 个商品，而且这 N 个商品还分开为 N 个请求同时过来？ 猜测的。 建议 OP 把架构放出来比较好给出建议。 |
 | 87 JKeita 2023-12-14 17:04:52 +08:00 确定不是被人攻击了？ |
| 88 G64q9J89mN5KSgmE 2023-12-14 17:10:20 +08:00 200 万并发？地球上有这样的应用场景 |
 | 89 ymy3232 2023-12-14 17:13:35 +08:00 我们的 api 接口高峰时段大概 3.5w req/s rt 平均 600ms 用了一个 LB 加 10 个 4c8g 的 ECS 感觉绰绰有余， 核心服务在架构的时候只依赖 redis ，去除了一切对 rt 有影响的中间件都改用 redis 实现，对于我们来说加到 20w req/s 也只是加机器的问题，但是 200w 也不太敢想 |
 | 91 ShaoLongFei 2023-12-14 17:16:14 +08:00 ec2 + auto scaling ，wlb + sqs |
 | 92 RipL 2023-12-14 17:25:34 +08:00 下单 12w+ 快赶上淘宝的双十一了吧 200w 比淘宝双十一都要牛逼了 |
 | 93 burymme11 2023-12-14 17:27:59 +08:00 萌新 蹲一个后续。 |
 | 94 4771314 2023-12-14 17:32:04 +08:00 12w 的下单 qps ，我的乖乖，赚大发了啊，快去把阿里淘宝的总架构师挖过来 |
 | 95 hefish 2023-12-14 17:32:44 +08:00 走，先找 dell 买服务器去，啊不对，买回来没地方堆。。 找当地政府要块地，先建机房。。。咳咳。。。 |
 | 97 8355 2023-12-14 17:34:46 +08:00 那不是说明不应该用 Lambda 吗。。。 你们这个架构做的啥玩意啊。。 |
 | 98 j519 2023-12-14 17:43:37 +08:00 你老板没那个实力拿（赚）那么多钱干什么？ |
 | 99 urlk 2023-12-14 17:46:48 +08:00 淘宝都没你牛 |
| 100 wqhui 2023-12-14 17:53:16 +08:00 我觉得思路是尽早拦截过滤无效请求、合并小请求、按地域把流量划分到不同机房 |
Select Language