高并发系统设计：从理论到实践，一个裸辞半年老码农的血泪复盘
去年十月，我从一家腾讯系大厂提了离职。不是因为被裁，也不是因为受不了“奋斗”，纯粹是想停下来喘口气。Gap这半年，白天遛狗、晚上看源码，一度以为自己要彻底躺平。结果今年三月，朋友内推了个深圳本地的高并发项目，说“你之前搞过分布式，来救个火？”——我心想，不就是写代码嘛，能有多难？直到真正接手才发现，高并发这玩意儿，光看论文和开源项目真不够用。
一场双11压测引发的“中年危机”
新公司的核心业务是个实时竞拍系统，峰值 QPS 要求 10w+。第一次参加压测评审会，产品经理笑眯眯地说：“我们希望用户点‘出价’按钮后，300ms 内看到结果。”我坐在角落默默打开 Chrome DevTools 看自家前端加载速度，心里咯噔一下——这哪是产品需求，这是性能死刑通知书。
更离谱的是，系统架构还是典型的“单体+MySQL主从”模式，缓存层只有 Redis 做简单 KV，连消息队列都用得抠抠搜搜。运维大哥私下跟我说：“上个月双11，DB CPU 直接飙到 100%，我们靠重启撑过去的。”我当场瞳孔地震：这不就是我当年在鹅厂踩过的坑吗？
但这次没人给你兜底。没有 SRE 团队帮你调优，没有 DBA 手把手优化慢查询，连监控告警都是 Grafana + Prometheus 自己搭。作为一个 Gap 半年后重新就业的“高龄”程序员，我必须把理论知识快速落地成能跑的系统。
从“纸上谈兵”到“线上救火”
缓存不是万能的，但没缓存是万万不能的
我第一个动作是重构缓存策略。原来的逻辑是“查 DB → 写 Redis → 返回”，典型教科书式写法。但在高并发下，缓存穿透、击穿、雪崩三件套轮番上阵。特别是竞拍结束那一秒，成千上万请求同时查“最终胜出者”，Redis 瞬间变透传层，DB 直接跪了。
解决方案？多级缓存 + 本地缓存预热。我在服务层加了 Caffeine 本地缓存，配合 Redis 的分片策略。关键数据（比如当前最高出价）在拍卖开始前就预热进缓存，用定时任务每秒刷新。这样即使 Redis 挂了，服务还能撑个几秒。
// 伪代码：本地缓存 + Redis 双写
LoadingCache<String, Bid> localCache = Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(2, TimeUnit.SECONDS) // 竞拍数据时效性强
.build(key -> loadFromRedisOrDb(key));
public Bid getHighestBid(String auctionId) {
return localCache.get(auctionId);
}
效果？压测时 QPS 从 8k 提升到 45k，P99 延迟从 1.2s 降到 220ms。运维大哥看监控图时差点流泪：“终于不用半夜被 PagerDuty 叫醒了。”
异步化：让系统学会“拖延症”
同步写 DB 是性能杀手。每次出价都要写记录、更新状态、发通知，串行执行肯定扛不住。我引入了 Kafka 做异步解耦，把非核心操作（比如日志、通知、积分计算）扔进消息队列。
但这里有个坑：消息顺序性。同一个用户的多次出价必须按序处理，否则可能出现“先出高价再出低价”的诡异情况。解决方法是 Kafka 的 key 分区策略——用 userId 作为 key，保证同一用户的消息落在同一分区。
# Kafka Producer 配置示例
spring:
kafka:
producer:
key-serializer: org.apache.kafka.common.serialization.StringSerializer
value-serializer: org.springframework.kafka.support.serializer.JsonSerializer
不过测试同学立刻跳出来：“如果消息重复消费怎么办？”好问题！于是我们在 DB 层加了幂等性校验，用 request_id 做唯一索引，重复请求直接返回成功。
数据库：别再让 MySQL 当全能选手
原来的表结构简直是灾难：一张 bids 表存了所有出价记录，外加一堆冗余字段。高峰期 SELECT * FROM bids WHERE auction_id = ? ORDER BY price DESC LIMIT 1 直接拖垮主库。
我们做了三件事：
- 读写分离：写走主库，读走从库（但注意主从延迟！）
- 分库分表：按
auction_id哈希分 16 库，每库 16 表，用 ShardingSphere 实现 - 冷热分离：历史数据归档到 TiDB，热数据留在 MySQL
最骚的操作是引入了 Embedding 向量近似搜索。别误会，不是搞 AI 推荐——而是把“相似出价行为”编码成向量，用于风控。比如某个 IP 短时间内高频出价但金额规律，可能是机器人。我们用 Faiss 做向量索引，QPS 5k+ 时响应 < 50ms。
| 方案 | QPS | P99 延迟 | 运维复杂度 |
|---|---|---|---|
| 原始单体 | 8k | 1200ms | 低 |
| 多级缓存 + 异步 | 45k | 220ms | 中 |
| 分库分表 + Embedding | 110k | 180ms | 高 |
工具链：Lovable 和 Replit Agent 救我狗命
说实话，Gap 半年让我对新工具有点脱节。入职第一周，我还在用 Postman 调接口，结果发现团队都在用 Lovable —— 一个国产的 API 协作平台，支持自动生成文档、Mock 数据、甚至能直接生成 Go/Java SDK。最爽的是，它能根据 OpenAPI Spec 自动生成前端 TypeScript 类型，再也不用和前端吵“你这个字段到底是不是必填”。
而 Replit Agent 则成了我的“深夜编程搭子”。有天凌晨两点，我在调试一个分布式锁死锁问题，Replit Agent 直接建议我用 Redlock 算法替代单 Redis 锁，并附上 Redisson 的配置示例。虽然最后没用它的方案（生产环境不敢乱试），但至少帮我理清了思路。
这些工具让我意识到：高并发系统不仅是代码，更是工程效能的比拼。你优化得再好，如果测试、部署、监控跟不上，照样翻车。
血泪教训：那些没人告诉你的细节
连接池不是越大越好
我一开始把 HikariCP 的maximumPoolSize设成 100，结果数据库连接数爆了。后来压测发现，最佳值其实是(core_count * 2) + effective_spindle_count，我们最终设为 32。日志是性能黑洞
生产环境千万别用System.out.println！我们曾因一条 debug 日志导致 GC 停顿 800ms。现在全用 SLF4J + Async Appender，日志异步刷盘。监控必须前置
上线前没埋点，出问题只能靠猜。现在每个接口都有traceId，Prometheus 抓取 JVM、GC、DB 连接数，Grafana 看板一目了然。别信“理论上可行”
有个同事提议用 Redis Stream 替代 Kafka，理由是“轻量”。结果压测时内存爆炸。记住：生产环境只认数据，不认论文。
最后一点感悟
裸辞半年后重回职场，最大的感受是：高并发系统设计，本质是“在约束中跳舞”。你有完美的理论模型，但现实是服务器要钱、人力有限、deadline 不等人。有时候，一个简单的缓存预热，比花里胡哨的微服务拆分更有效。
我现在每天上班第一件事，不是写代码，而是看监控大盘。当看到 P99 稳稳压在 200ms 以下，用户投诉率下降 70%，那种成就感，比当年在大厂拿股票还爽。
所以，别怕从零开始。哪怕你 Gap 了一年，只要肯动手、敢踩坑，代码世界永远欢迎你回来。
（完）
P.S. 本文所有方案已在生产环境稳定运行三个月，双11大促零故障。老板说要请我吃海底捞，但我只想早点下班遛狗——毕竟，打工人的终极目标，不就是拥有随时说“老子不干了”的底气吗？
评论 0