三年前老板扔给我一个需求做一个能扛住十万并发的秒杀系统。我当时只会写CRUD硬着头皮上了。上线第一周系统崩了四次每次都是半夜被叫起来救火。一年后这套系统稳如老狗QPS峰值跑到十二万。回头看高并发不是靠堆机器堆出来的是一层层设计出来的。第一步把单体拆成微服务一开始所有代码都在一个Spring Boot应用里订单、库存、用户、支付搅在一起。压测一跑改库存的锁把整个应用拖死。我按业务域拆成四个服务用户服务、商品服务、订单服务、库存服务。拆分的核心不是越小越好是让每个服务能独立扩容。秒杀时订单和库存压力最大单独加机器就行不用整个系统一起扩。服务间用Dubbo做RPC注册中心用Nacos配置动态刷新改参数不用重启。第二步缓存扛住读MQ扛住写商品详情页每秒被刷几十万次直接查数据库必死。我把商品信息塞进Redis用Hash结构存一个key搞定。热点key用本地缓存Caffeine再挡一层减少Redis网络往返。缓存的核心不是加一层是设计好失效策略。我设置了随机过期时间防雪崩用布隆过滤器挡穿透热点数据永不过期但后台异步刷新。写请求全走MQ。用户下单后消息扔进RocketMQ订单服务慢慢消费。同步写改异步写响应时间从200毫秒降到20毫秒。但异步必须解决幂等我用订单号做去重表重复消费直接丢弃。第三步数据库分库分表加读写分离订单表三个月就破了五千万行。我按用户ID哈希分十六个库每个库再按月份分表。分库分表的核心是选对分片键选错了查询跨片性能更差。用户ID做分片键保证同一个用户的订单落在同一个库。读写分离用ShardingSphere写主库读从库主从延迟用半同步复制压到毫秒级。第四步限流熔断降级三件套秒杀开始瞬间流量是平时的五十倍。我在网关层用Sentinel做限流每秒放一万个请求进来多余的直接返回“排队中”。限流不是拒绝用户是保护系统活着。下游服务配熔断库存服务响应超过500毫秒就熔断快速失败返回兜底数据。降级方案提前写好Redis挂了走本地缓存MQ挂了走同步写但限流阈值砍半。第五步压测调优数据说话每加一个组件我都用JMeter压一遍。线程池参数、连接池大小、JVM堆内存、GC策略全部根据压测数据调。没有压测的优化是自嗨你永远不知道瓶颈在哪。最终调优后单机QPS从800干到8000响应时间P99控制在100毫秒以内。第六步监控告警别等用户投诉Prometheus采集指标Grafana看大盘SkyWalking追链路。CPU、内存、QPS、RT、错误率全部设阈值告警。高并发系统不是不出问题是出问题能秒级发现。有一次Redis集群主节点挂了告警三十秒内推送到手机我还没爬起来自动故障转移已经完成了。这套系统从零到十二万QPS用了一年。没有黑科技全是基本功拆服务、加缓存、上MQ、分库分表、限流熔断、压测调优、监控告警。高并发不是一蹴而就的是一层层叠出来的。你每做好一层系统就多扛一万并发。别想着一步到位先把第一层做好再叠第二层。