如何从零搭建一个高并发的后端服务

结论：高并发后端不是靠堆机器堆出来的，而是按「量化目标 → 单机压测找瓶颈 → 服务无状态水平扩展 → 逐层加缓存和异步 → 限流熔断兜底 → 全链路压测回归」六步做出来的工程结果。跳过压测直接上分库分表，等于给自己制造故障。

高并发后端从哪一步开始？

结论：第一步是量化目标，不是选框架。先算峰值 QPS，公式是「峰值 QPS = 日请求总量 ÷ 86400 × 峰值系数」，互联网业务峰值系数取 3-5。日请求 1 亿次，平均 QPS 是 1157，按系数 4 算，峰值 QPS 为 4600，这个数字才是后面所有容量设计的输入。

同时定三个硬指标：峰值 QPS、P99 延迟（接口 200ms 以内）、错误率（低于 0.1%）。指标没定死，调优就没有判断标准。

单台服务器能扛多少 QPS？

结论：先压出单机上限，再决定扩不扩容。4 核 8G 机器上，Nginx 返回静态文件跑到 3 万-5 万 QPS；Spring Boot 简单查询接口 1500-3000 QPS；MySQL 单机主键查询 3000-5000 QPS；Redis 单实例 8 万-10 万 QPS。

压测工具用 wrk、JMeter 或 Locust，看 P99 而不是平均值——平均值 50ms、P99 两秒的服务，用户体验就是卡。找到第一个被打满的资源（CPU、连接数、磁盘 IO、数据库），它就是当前瓶颈。

为什么服务必须做成无状态？

结论：只有无状态才能水平扩展。把 session 从本地内存搬到 Redis，本地缓存改成 Redis 或按一致性哈希分片，上传文件放对象存储。改完之后加机器就能线性提升吞吐，前面挂 Nginx 或云负载均衡做轮询分发。

扩容有上限：每加一层转发就多一次网络跳转，Nginx 单机反向代理上限在 2 万-5 万 QPS，再往上要靠 DNS 轮询或多层 LB。

缓存怎么加才有效？

结论：缓存命中率低于 90% 就是无效缓存。用户信息、商品详情、配置这类热点数据前置到 Redis，读多写少的场景把命中率做到 95% 以上才算合格。

三个必防的坑：缓存穿透用布隆过滤器或空值缓存挡住不存在的 key；缓存击穿用互斥锁或逻辑过期，防止热点 key 失效瞬间打穿到数据库；缓存雪崩把所有 TTL 打散，在基础过期时间上随机加减 10%。

数据库扛不住怎么办？

结论：按成本从低到高依次尝试——加索引、读写分离、垂直拆表、分库分表。先打开慢查询日志（long_query_time=1），把 1 秒以上的 SQL 全部干掉，数据库压力能直接下降一个量级。

再上主从复制做读写分离，写主库读从库，注意主从延迟：下单后立刻查订单这类一致性敏感场景必须强制读主库。分库分表是最后手段，一旦分片，跨片 join 和分布式事务成本成倍上升。写入峰值用 Kafka 或 RocketMQ 削峰，消费者按自身能力拉取，用业务唯一键加去重表做幂等。

限流、熔断和连接池参数怎么设？

结论：保护自己比满足所有请求更重要。入口限流用令牌桶（Sentinel 或 Guava RateLimiter），阈值设成压测峰值的 70%-80%，超出的请求快速失败。

熔断用 Sentinel 或 Resilience4j，错误率超过 50% 熔断 10 秒再放量探测。连接池按公式调：HikariCP 的 maximumPoolSize = CPU 核数 × 2 + 有效磁盘数；Tomcat 线程数按利特尔法则算，线程数 = 目标 QPS × 平均响应时间（秒），2000 QPS × 0.05s = 100 个线程。

怎么验证真的扛得住？

结论：上线前必须做一次到目标 QPS 1.5 倍的全链路压测。压测环境与线上同规格、数据量同量级，覆盖缓存命中和不命中两条路径。

监控用 Prometheus + Grafana 采指标，SkyWalking 或 Jaeger 做链路追踪，盯住 QPS、P99、错误率、CPU 使用率、GC 暂停时间、连接池活跃连接数六项。压测出现拐点（QPS 上不去、P99 陡增）就说明到了容量上限，加机器或加缓存后重压一遍。

从零搭高并发后端，顺序就是量目标、压单机、去状态、加缓存、拆数据库、设限流、压全链路。这套流程里最贵的不是机器，是没压测就上线的自信。