你的 AI 应用被推荐了。它扛得住流量暴涨吗？

想象一个糟糕日子里好的那个版本。你在自己所在的社区里发布了用 AI 做的应用，或者某个粉丝众多的人试用后分享了它，又或者它登上了某个你压根没投稿的论坛首页。突然之间，你习以为常的零星访客变成了洪流。一千个人，全在同一个小时里点来点去。

这正是你做这个东西所等待的时刻。但这也常常是很多 AI 应用悄无声息地崩掉的时刻 —— 页面卡顿、转圈加载、注册表单提交不了。终于来了的那些人撞上了一堵墙，然后离开，而其中大多数人再也不会回头重试。

好消息是：扛住流量暴涨，关键在于在暴涨发生之前做对的那几个看起来很无聊的决定。你不需要是工程师，你只需要知道哪些弯不能抄。

流量激增时，到底是什么先崩

当使用你应用的人数突然变成平时的一百倍，崩溃并不是随机发生的。它会以一种可预测的顺序发生，而且几乎总是同样的三个地方。

**数据库被压垮。**每次有人加载页面，你的应用通常都会向数据库问一个问题：“这个用户的数据是什么？“一个人问没什么，但一千个人在同一分钟里问同一个问题，堆积的速度会快过数据库能回答的速度，于是所有人的页面都慢成了爬行。

**应用之外的某个东西变慢了。**大多数 AI 应用都依赖其他服务 —— 发邮件、处理支付、调用 AI 模型。这些服务往往会限制你调用它们的速度。在正常流量下你从没注意过这个限制。可一旦流量暴涨，你的应用就撞上了它，于是每一个涉及那个服务的操作都突然卡住了。

**应用一遍又一遍地做同样的重活。**如果你的主页在每一次有人访问时都要跑一次繁重的计算 —— 拉取一个列表、排序、再格式化 —— 那么对十个访客来说没问题，但对一千个访客来说就是一场灾难。这份活儿本来就一直很浪费，只是低流量把它掩盖住了。

注意这里的规律：这些都不是新出现的 bug。流量暴涨没有弄坏任何东西，它只是揭露了原本就存在、在低流量下安安静静潜伏着的那些弱点。

最便宜的解法：把不会变的东西缓存起来

缓存听起来很技术，但道理其实很简单：如果某个问题的答案对所有人都一样，而且很少变化，那就算一次、然后反复复用，而不是为每个访客都重新算一遍。

你的主页对那 1000 个访问者来说很可能长得一模一样。那为什么要让数据库把它重建 1000 次呢？算一次，把结果存上几分钟，再把这份存好的副本发给所有人。你就这样把一千次昂贵的数据库往返变成了一次。

直接这样告诉你的 AI 构建器：“把主页和公开商品列表缓存五分钟，这样每次访问就不用都去查数据库。“任何对所有人都一样、又不需要精确到每一秒的东西 —— 一个价格页面、一个公开列表、一个博客目录 —— 都是缓存的候选项。个性化的东西（某个人自己的仪表盘、他的账户设置）没法用同样的方式缓存，但在流量暴涨期间，这通常只占流量的一小部分。大多数人看的都是那同样的几个公开页面。

别让人为那些可以稍后再做的事情干等

这是一个很容易犯、也很容易修的错误。比如有人注册了，你的应用要给他发一封欢迎邮件。如果你的应用让他停在注册页面上干等，直到邮件完全发出去，那么一个慢吞吞的邮件服务就会拖慢你的注册流程 —— 而这恰恰是最多人在注册的时刻。

解法是让慢的事情在后台进行。那个人会立刻看到”你已经加入了！“，而邮件在几秒钟后悄悄发出，没人需要为它等待。结果是一样的，但访客不必盯着转圈，等一个隔了三家公司远的邮件服务器慢慢悠悠地处理。

跟你的构建器说：“在后台发送欢迎邮件，这样注册就不用等它。“同样的逻辑适用于任何不需要在用户继续操作之前完成的事情 —— 生成报表、同步到另一个工具、发送通知。如果用户不需要现在就拿到结果，那就别让他等。

准备一个”人太多了”的预案

有时候流量暴涨会大过你所做的任何准备，这时候诚实的做法是优雅地降级，而不是彻底崩塌。一个还能用的慢应用，胜过一个坏掉的应用。

这有几个简单的版本：

• **一句友好的等待提示。**如果某个东西确实被压垮了，显示一句”我们现在访问的人特别多 —— 请稍等片刻”，远比一个空白屏幕或一条原始报错要好得多。人们会原谅一个忙碌的应用，但不会原谅一个坏掉的应用。
• **临时关掉最重的那个功能。**如果某一个功能特别费资源 —— 比如每次点击都要花真金白银和时间的 AI 生成 —— 你可以在流量激增时把它藏起来，让应用的其余部分保持流畅。反正流量暴涨期间的大多数访客是在浏览，而不是在用你最吃资源的那个功能。
• **搞清楚你的账单从哪来。**如果你的应用每次访问都要调用一个付费的 AI 模型，那么一千个访客可能意味着一笔意外账单，而不只是一个慢页面。知道哪些操作要花钱，能让你提前决定要给什么设上限。

一场三十分钟的彩排

你不需要花哨的工具来找出自己的薄弱点。你需要的是几个朋友和半个小时。

请五六个人在同一刻打开你的应用，然后用力点上几分钟 —— 注册、用主要功能、加载那些繁忙的页面。这招很粗糙，但能很快把明显的问题暴露出来。如果六个人猛敲就已经让应用感觉吃力了，那一千个人会把它直接压垮。如果它依然反应敏捷，那你至少跨过了最低的那道门槛。

在他们点击的时候，留意哪个页面感觉最慢。那个慢页面正是真正的流量暴涨最会伤到的地方，也是最值得优先缓存或简化的对象。你不是要去模拟一千个用户，你是要找出那一个在六个人时就已经吃力的页面。

真正的目标

你没法把应用做到无限坚不可摧，你也不需要。目标不是在第一个爆红时刻就完美无瑕地接住一万个人，而是别在终于来了的那几百个人面前丢脸 —— 是确保你费尽心力吸引来的那些人拿到的是一个能用的应用，而不是一个转圈的圈圈。

把不会变的页面缓存起来。把慢的事情挪到后台。准备一个”人太多了”的预案。在你需要它之前，先做一场五个朋友的彩排。这些都不需要你自己写代码 —— 只需要知道该向你的 AI 构建器要什么。

然后，当你的时刻到来时，你就能去享受它，而不是手忙脚乱地排查 bug。所以本周值得静下来想一想这个问题：如果明天来了一千个人，哪个页面会最先崩 —— 你现在就知道吗？