2019年我们做一场抢购活动，目标峰值设定10万QPS，结果凌晨一点瞬间来了一波机器人流量，直接把订单中心打崩了。当时我盯着监控大屏，心里只有一个念头：完了，这个季度的绩效要没了。事后复盘，我们其实准备了8台机器，做了缓存预热，还上了服务限流，但依然没有扛住。后来才发现，问题出在数据库的一条库存记录上，所有请求都挤在那一行数据上，连接池瞬间被占满，其他正常请求也一起被拖死。那次事故让我开始怀疑，我们天天讲的“高并发技术”，是不是从一开始方向就错了。
这几年我见过太多团队，一提到高并发就条件反射地加机器、加缓存、分库分表，好像把这些关键词堆上去，系统就无敌了。但实际跑起来，很多系统还是会在某个下午被一个热点新闻打崩。有一回我负责一个支付对账模块，峰值请求也不低，但它是异步的，先把消息写到队列，再慢慢消费，系统稳如老狗。所以你看，同样一个量级，同步和异步业务的做法完全不一样。高并发不是一种技术，而是很多种问题杂糅在一起，你得分场景去处理，而不是拿一套模板硬套。
我现在的观点可能有点反主流：高并发本质上根本不是什么匀速的大流量，而是“热点”和“突变”。平时系统可能只有几百QPS，但某个瞬间所有流量都集中到少数几个数据项上，比如一个热门商品、一个顶级主播的直播间。这种情况下，加机器没用，因为热点落在单机上，你没法把它分片。更麻烦的是，热点还会放大，前端一个重试策略就让所有流量再翻好几倍。所以设计时真正要做的，是“热点隔离”和“削弱放大”，而不是盲目追求能扛多少吞吐。比如库存扣减，别直接update数据库，改成异步合并请求，或者用更重的分布式锁，但把冲突概率降下来。
再说说限流，限流不是万能的，做不好反而坑自己。我们曾经给推送接口加了令牌桶限流，结果大促的时候，正常用户的请求被限掉了，机器人的流量倒没挡住，因为它们是分布式的，打到了不同网关节点上。后来改成基于用户维度的权重，再结合登录态判断，才把正常用户放进来。比限流更重要的是降级。抢购的时候，如果非核心功能（比如推荐列表、消息通知）挂了，就直接返回默认数据，别让它们去抢数据库连接。库存计数器也不能强求强一致，用最终一致，把并发冲突变成顺序写，一会儿就能追上。
最后想说，高并发没有银弹，但有一点是肯定的：工程师要学会和业务方打群架，而不是自己埋头调参数。你需要弄清楚，哪些功能在负载高的时候可以丢掉，哪些流程必须保证成功。把关注点从“每秒能处理多少请求”换成“能容忍多少失败”，这个视角转变比任何技术栈都重要。反正当年我要是早明白这个道理，也不至于在监控室里蹲到天亮。
