一杯奶茶打爆了一个key

前言

先在前面简单说一说自己要写什么（以防止你觉得我太跳脱了hh）。差不多有这几个部分：

1. 关于“秋天第一杯奶茶”爆火的原因
2. 关于奶茶商业逻辑的思考以及（高并发）技术实现
3. 对整件事情的其他一些思考

听着蛮寡淡的，但相信我下面说起来还蛮有意思的。

首先先来说一下引发我思考的事件：

8月7日是立秋，幸福的我也喝上奶茶啦啦啦。虽然本人对于这种东西不是很感兴趣的（并且认为是资本的噱头），并且也不是很喜欢吃甜、喝奶茶这些，但是想到有人挂念我真的还是好感动www。

友友给我的古茗的心意券。当时点进去古茗看到有400杯正在做，给我惊呆了。然后我就感兴趣了，为什么它家会有这么多杯、生意会这么好呢？ 这是我其一的思考。

并且收到券我就要去用啦，于是在“新增地址”这个功能看到了这样的问题：

！！这个对于计算机的我们来说，我真的很兴奋。于是就开始深入了。并且当时留意了一下，是过了比较长时间才给修好的。
（以及为了严谨性补充一点，已证实老用户可以正常下单）

我倒是多思考了一下他们奶茶的商业逻辑和技术实现，

然后当天和一个朋友也聊了。他更关注这种兴起之类的，并和我说了类似，他三四年前恋爱的时候就有。但是不是很热门，关于时间差之类的。
我也专门去搜了下，其实这梗起源挺单纯的, 2020年秋分一张晒52元红包的截图, 当天就上热搜了, 奶茶店当时都懵了, 是后面才借势的。所谓黄梗/分手梗都是火完以后网友考古出来的都市传说，不是起源。

关于朋友说的当时不热门，感觉应该也是接触它时候为私人仪式期（puq零星还蛮少的），后面完成了社会制度化。然后嘛每届大学生都是“第一次”过秋一杯，所以永远新鲜。

那么接下来就要从三个方面说道说道了，

“秋天第一杯奶茶”爆火的原因

“谐音梗+红包社交+季节仪式感”。大部分梗是烟花，这个梗是节气。

像我当时上面简单概括一样，起源确实很简单。很多东西的起源都蛮简单的，诸如….之类（这个此处我就不多说了）

想了一下，主要有这几点原因：

1. 商业力量。我觉得这个是主要的成分，也是我最先想到的。笑死，想到当时搜索资料，看到这些奶茶商家，刚开始被这个“热点”都搞蒙了、也没想到，然后赶快抓住商机，哈哈。
   品牌方发现这个梗能直接带货后，每年立秋都主动营销。因为这个梗有商业利益，所以被资本反复推上热门啦。纯娱乐梗就没有这种待遇了。

2. 自带日历锚点。普通梗依赖某个新闻事件或人物，热点一过就没人提了。“秋天第一杯奶茶”绑定在二十四节气的“立秋”上（其实刚开始起源的时候还不是立秋呢），自带年度闹钟，复活机制极好。

3. 低成本、高社交回报。这个不必多说，这个会比单纯“好笑”梗寿命长很多。好笑会疲劳，“有用”不会。不过我觉得这个倒是个不错的商业入口点。

4. 参与门槛低。对比那些需要“懂梗”的小众梗（如某个游戏黑话），它的传播面宽了几个数量级。

甚至推广一下。还能衍生出“冬天的第一顿火锅”“夏天的第一支雪糕”等等。这类现象在传播学里有个学名呢，“模因的仪式化”。

啊关于古茗在我当时点进去能达到 400 多杯，这里说两嘴。想起了朋友之前和我说的，古茗是做冷链出身的。相关的处理都比较好，

之前抖音上面也是看到过这种视频，以及古茗后面做起了咖啡 的商业逻辑相关的 嗯 论述，说的都好好。
大体也是说，判断一家连锁能不能做咖啡，不只是看它会不会调配方，而是看它背后有没有稳定的供应链（仓库和冷链）。

奶茶业务逻辑及（高并发）技术实现

这个是我最最先开始考虑的部分、引起我深度和广度思考的部分。这部分我也会说的相对多一点。

现象归因

首先关于古茗的 已达key最大调用次数 报错：

1. 原因类型：（某个第三方）API的调用配额耗尽。古茗小程序调用了地图这个需要 key的接口。（同类有配额限制的依赖还有支付、消息推送、验证码、营销活动接口等）
2. 触发条件+症状：立秋+奶茶打卡活动流量暴涨，导致 API 配额被打满，接口直接报错。

奶茶连锁普遍有营销创意、但很多技术方面有待加强。拿本次古茗来说，业务想法非常好，但立秋峰值暴露了第三方接口容量没准备够，兜底体验也没做好。

问题定性：一次高并发故障

首先来看一下 高并发本质：在有限资源下，让系统在大流量下依然保持“低延迟、高吞吐、高可用”。

有限资源 = 自身算力 + 外部依赖配额（第三方 API、短信通道、支付通道）

流量涌入速度 ＞ 资源供给速度，不管是自家的资源还是别人家的资源，供不上都是高并发问题。

（不过，实际工程场景中，当流量远远超过系统承载上限时，是无法安全兼顾三者的。现代架构通常会实施有损服务，通过限流、熔断、过载保护 牺牲一部分边缘请求，优先保全核心业务的高可用，并让成功处理的请求维持在可接受的延迟内。）

那么关于本次的古茗，可以说是比较典型的“高并发场景+依赖治理翻车”复合案例。有做对的地方（如隔离），也有缺失的（降级、容量规划、限流）。

拆开看：

1. 场景层面：

• 立秋 = “秋天第一杯奶茶”流量洪峰，瞬时 QPS 数量级跃升
• 老客复购洪峰 + 新客首单洪峰叠加 → 海量新用户首次点单 → 触发新增地址 → 地图 API 配额被打爆

2. 依赖层面：

• 已达key最大调用次数 → 地址模块背后大概率在调用第三方地图 API（高德/腾讯之类），key 有 QPS 或日配额上限。这时给自己加再多服务器都没用，因为打满的是别人的配额。

不过这个故障暴露的并不是自身算力的不足，而是外部依赖配额管理的问题。

只有新用户才报错，用户量大到把只有新用户才走的那条窄路径的配额都打爆了。
→ 当时流量是“老客复购 + 新客”双重洪峰叠加，恰恰拉新的黄金期，被挡住在门外的全是最值钱的增量用户。

核心链路拆解

回到普通点单业务，核心链路就可以是：
选择门店/地址 → 选商品 → 创建订单 → 支付 → 门店履约。
像是“推荐活动、地图预览、营销弹窗”等，一般是非核心功能。

但对此前没有保存地址的人来说，具体场景为：
新增收货地址 → 校验配送范围 → 创建订单 → 支付

正常来说，地图搜索功能可能包括：
输入关键词 → 地址联想 → 地图选点 → 经纬度解析 → 配送范围判断

四维复盘

1. 隔离 ✅

整体看下来古茗其实隔离做得还是不错的，地图 API 只挂在“新增地址”这个子路径上。配额打爆后老用户下单并不受影响，可以看出来核心交易链路不依赖第三方增强功能。

2. 降级 ❌

降级姿势不对。配额耗尽时，正确做法是让新用户手动输入纯文本地址兜底（不调地图 API，直接入库），或者降级成“城市+区域”粗粒度选择。直接甩一句报错，反倒会劝退大量的新客户。

这也是“地址输入是长尾查询、缓存命中率有限”场景下的一个兜底思路。缓存解决不了长尾，降级才能。（不过也有限制，外卖配送通常需要经纬度、距离和门店配送范围，纯文本地址不一定能立即完成履约判断）

地图接口不可用时，可以降级为：

• 省、市、区使用本地行政区数据选择
• 用户手动填写街道、门牌号
• 允许选择附近门店，再填写详细地址；
• 保存为“待校验地址”，恢复后异步补充经纬度

3. 限流 ❌

真正做的比较好的限流，通常表现为：

• 控制同一用户短时间内反复搜索；
• 输入地址时防抖，例如停止输入300ms后才查询；
• 相同地址查询用缓存
• 接近配额阈值时限制非关键地图请求；
• 给用户显示友好的“当前查询繁忙，请稍后重试”，而不是暴露 Key 报错

本次是错误直接暴露了给用户，配额监控、入口限流或异常处理至少有一处不足。
（但是说起来，也是经历的太少了，看到好多真实业务场景中确实是乱写了。或者说标准其实才是“理想状态”）

4. 容量规划 ❌

容量规划漏了外部配额。立秋每年都有，key 的日配额/QPS 是可以商务采购提前扩的。
此外其他常见做法还有多 key 轮换、配额阈值告警+自动降级开关。

核心链路保住了（隔离做对），但降级方案缺失（应当优雅降级，而不是硬报错）+ 配额预估不足（可预知洪峰没提前扩容）。

这里放一张表格：

其他思考

经验。把握商机。情感化赠卡差异化模块 (这个了解不是很深，感觉是需要比较好的调研一下并且因地因景制宜了)

关于整个事件宏观看一下。暴露出来的问题主要就这个。
技术上应当负责。
以及感觉产品、运营方面也要负责，应该搞个预售预约、错峰领券之类的。

其他倒是很正常的（也说是“没出问题就是好的”了hh），但如果遇到极端情况（比如这天大量用户涌入）呢？能否提前预判做好一些准备？以及假设事情发生了、能否及时快速处理好？这些都是考验。
流量大会不会被打穿？订单能都及时交付？在商业视角，每一秒损失的都是钱。

当时还和朋友们谈了一些其他的方面。包括学校的教务系统之类的也是，如果做扩容，平时成本上会浪费不少。
比较常见的还是购物平台在“购物节”上的处理，但是这个技术栈（技术实现上）用的还是比较少的。平时去用人单位啦，大部分上多数业务还是用不到的 还是少数嘛，从比例上来说 不只是指份额。

朋友当时还提到，某种程度上可以借鉴12306，但是12306这种属于国家机器。于是我想到了另一个朋友给我转的视频：
12306（点击跳转）
不是特别相关的，但是感觉这个视频真的不错，推荐去看看（1min23s）。
它可借鉴的点：削峰填谷、异步排队、候补队列，本质上是请求队列 + 异步履约。
于是：“是的啊，12306这个也很难借鉴了，不可能付出这么多开发成本”，hhh

小小尾巴：
（因为时间太久了，好多地方都有些忘了www。所以有事情还是要早点抓紧做完的。不然真的就是越来越拖越来越拖了，
以及好多地方，在后面的视角来看，割裂感还蛮严重的）

不过说来人的观念看法确实是在动态变化的。很多事情在现在或者说后面的视角看了一下，就不是很认同、有了新的见解了。
以及前段时间朋友就“学生jump off楼多发引发的关于不同阶ji身份权利 ge命 改ge 资源 时代 个人做法全局视角之类” 发表了观点。我说了些我的看法，他其中一句话大概是，我的一些认知不像是我这个年龄该有的。很多东西你现在视角看是这样的，等你后面经历或有其他的接触后会有不一样的认知。
深感认同。在Youtube上看到这样一个视频，讲读书的重要性的。其中一句话就是，
“Your thoughts and your ideas are not your own. You have inherited them from your parents, from your culture, from your centuries of history. “
其实也会想到编程语言里的“继承”，用短句概括，应该可以说是 包括但不限于 或者 发展创新。