压测是优化的起点

没有经过真实流量压测的系统优化，就像蒙着眼睛过马路——迟早出事。我第一次接手高并发项目时，团队拍着胸脯说系统扛得住十万QPS，结果上线当天仅五千并发就把数据库打挂了。压测不是走形式，而是暴露系统脆弱点的核心手段。我们需要在压测中同时观察CPU、内存、网络IO、磁盘IO、GC次数、数据库连接池水位、线程池队列长度等十余个指标。压测工具推荐用wrk或locust，但更重要的是自己写脚本模拟真实业务场景中的随机读写、热点数据访问和突发流量。记住，压测数据要丢到线上环境或者至少同配置的预发布环境去跑，开发环境的小马拉大车毫无意义。

压测过程中最容易发现的第一类问题就是线程模型。常见的Tomcat默认有200个线程，但你想象不到的是，当每个线程都在等待数据库慢查询返回时，200个线程很快会被耗尽，新的请求只能排队。高并发下的首要瓶颈往往是线程池耗尽，而非CPU满负荷。这时候你需要重新审视业务接口的耗时分布——是磁盘写入慢？是外部RPC调用了？还是数据库连接池满了？我见过太多人一上来就加机器，其实把某个慢查询从500ms优化到50ms，一个节点的吞吐量就能翻好几倍。

从单线程到协程：并发模型的进化

Java领域长期依赖多线程，但线程是操作系统的重资源。随着Go语言的流行和Java的虚拟线程（Project Loom）引入，协程正在成为高并发场景下的最优解。原因很简单，一个线程占用约1MB的栈空间，而一个协程只需要几KB，因此单机可以轻松开启数十万甚至百万个协程。在类似网关转发、批量请求聚合这类IO密集型场景，协程的切换成本远低于操作系统线程。我曾经将某个基于Netty的网关从线程池模型改为协程模型，同等硬件条件下QPS从3万提升到8万，而且CPU占用率还下降了。

但协程不是万能的。如果业务中有大量的CPU密集型计算，比如加密解密、图像处理，那么多线程的并行优势依然明显。正确的做法是区分IO密集型和CPU密集型：IO密集型优先使用协程或者异步回调，CPU密集型则保持固定数量的线程来匹配CPU核数。另外注意，协程的调度器需要精心调参，否则容易出现伪共享（False Sharing）或者协程饥饿。我建议在采用协程之前，先用Profiling工具仔细分析业务中到底哪些操作拉低了并发上限——很多时候，锁竞争才是真正的恶龙。

数据库的终极解耦：读写分离与分库分表

关系型数据库往往是高并发系统最薄弱的环节，因为它在设计之初就强调ACID，而高并发却要求CAP中取舍。读写分离是入门级的解放方案：主库负责写入，从库负责查询，配合数据库代理（如ProxySQL、MaxScale）自动路由。但要注意主从延迟问题——业务中如果刚写入立即查询，可能查不到数据。解决方案是强制读主库，或者让前端等待1秒再展示。我经历过一次事故：一个活动页面刚开奖就三万人同时查询，从库压力过大导致延迟飙升到10秒，用户看到开奖数据为空的假象，怒火中烧。后来我们在应用层加了“读主库标记”，只有开奖逻辑后的第一次查询才强制走主。

当读写分离也撑不住时，就要考虑分库分表。合理的分片策略是高并发场景下数据库的定海神针。常见做法是按用户ID哈希分库，按时间分区。但分片键选择至关重要——一旦选择错误，后续跨库查询、全局ID生成、分页排序都成了噩梦。我用过一个失败的案例：按业务类型分片，结果某个爆款业务类型占据了90%的流量，那个分片直接被压垮。后来改成按用户ID + 时间双维度分片，配合ShardingSphere的自动路由，才把流量平均散开。另外注意，分库分表后一定要建立“降级开关”，当某些分片出现故障时，可以快速切到备用分片或者直接降级为本地缓存，而不是直接返回500。

缓存不是银弹

很多团队一碰到性能问题就疯狂加缓存，但缓存带来的问题往往比解决的问题更多。缓存的核心是减少计算和IO，但缓存击穿、穿透、雪崩三大坑会随时引爆。我曾见过一个系统，所有商品详情都缓存30分钟，突然某个爆款商品被大量请求，缓存过期瞬间几十万请求打到数据库，数据库连接池瞬间爆满，导致整个站点瘫痪。解决方案是设置“热点数据永不过期+后台异步刷新”，或者使用互斥锁（setnx）让单一线程去重建缓存。布隆过滤器是防止缓存穿透的利器，它可以在缓存层面就过滤掉不存在的key，避免无效的数据库查询。

另外，缓存层本身也要做高可用。单节点Redis扛不住时，需要Redis集群（官方集群或Twemproxy）分片。但集群扩容和缩容时，数据的rehash可能导致大量缓存失效。我推荐使用一致性哈希（Consistent Hashing）或者Redis Cluster自带的slot分片机制，并且在客户端实现智能路由，避免请求打到错误的节点。同时，本地缓存（如Caffeine）和分布式缓存要搭配使用：本地缓存毫秒级响应，但容量有限，适合存储最热门的少量数据；分布式缓存容量大，适合存储大量但访问频率稍低的数据。热key问题一定不能忽视——某个热点Key的QPS超过单节点Redis的处理能力时，可以用本地缓存+分布式缓存双层架构，同时在客户端做key的随机后缀拆分，让请求散列到不同Redis节点。

异步化与消息队列

同步调用在高并发下会形成多米诺骨牌效应：A服务调用B，B调用C，只要C变慢，整条链路都被阻塞，线程被挂起，资源被占满。将同步调用改为异步化，是提升系统吞吐量的经典做法。消息队列（如Kafka、RocketMQ）是异步化的主流选择。比如用户下单后，扣库存、发优惠券、发短信等操作都可以通过MQ异步执行，主流程只需要保证订单创建成功即可。这样，下单接口的响应时间从几百毫秒降到几十毫秒，系统能承载的并发量立马翻倍。

但异步化也引入了新挑战：消息丢失、重复消费、顺序问题。高并发场景下必须保证消息至少投递一次，且消费端做好幂等。幂等实现方式可以是消费前查DB是否有唯一ID，或者利用数据库的唯一索引去重。我曾经遇到一个订单重复发货的严重事故，就是因为MQ重复投递且消费端没有做幂等。后来我们在每条消息里带上业务流水号（如订单号+随机数），消费时先查流水表，只要存在就放弃执行。另外，异步消息的积压风险也要提前预防——监控队列长度，设置告警，当积压超过阈值时自动触发扩容消费者。

限流与降级：保护系统的最后防线

无论优化得多好，总有流量超出系统承载的那一刻。限流不是限制用户，而是保护系统不会因过载而崩溃。常用的限流算法有令牌桶、漏桶、滑动窗口。我偏爱令牌桶，因为它允许一定程度的突发流量。在业务网关层（如Nginx、Spring Cloud Gateway）统一做限流，比在业务代码里手写更可控。例如配置每秒1000个请求的令牌桶，突发容量200，当流量超过时直接返回429（Too Many Requests），客户端可以配合重试策略。

降级则是在系统压力过大时主动牺牲非核心功能。降级策略要有优先级：先降级非必要的功能（如优惠券计算、日志统计），再降级阅读类功能（如评论区只显示前100条），最后才考虑降级交易核心。我在双十一大促中，把所有非核心的MQ消费者线程数缩减到1，同时关闭了商品推荐、用户画像等强依赖服务，换取了下单主链路的稳定性。一定要用配置中心（如Apollo、Nacos）动态开关降级，而不是改代码重启。另外，熔断器（如Hystrix、Sentinel）也是降级的重要工具，当某个依赖调用失败率达到阈值时自动熔断，快速失败，避免自己也被拖垮。

从全链路监控到智能运维

没有监控的优化等于盲人摸象。高并发场景下必须建立全链路追踪（Trace），从用户请求进入网关开始，到调用下游各个服务、访问缓存、读写数据库，每一步都要记录耗时和状态。推荐使用OpenTelemetry或SkyWalking，它们能生成调用链拓扑图，让你一眼看到整个请求的瓶颈在哪。我遇到过最奇葩的案例：某个接口从10ms变成500ms，全链路图显示是Redis GET操作耗时异常——进一步排查发现是因为那个Redis实例的AOF重写占用了大量CPU。

除了调用链，系统指标的实时监控同样重要。CPU、内存、网络、磁盘的基线数据要持续记录，当出现异常时能快速比对。比如CPU突然飙升到100%，如果同时GC日志显示Full GC频繁，大概率是内存泄漏或对象创建过多。如果网络带宽打满，则可能是某个热点数据被重复传输。我建议用Prometheus + Grafana搭建监控大盘，设置三个级别的告警阈值：黄色预警（关注）、橙色告警（通知oncall）、红色报警（触发自动扩容或降级）。自动弹性伸缩（Auto Scaling）是终极武器，结合Kubernetes的HPA，可以根据CPU、内存、自定义指标（如QPS）自动扩缩pod，但注意扩缩频率要设置冷却时间，避免频繁震荡。

最后一个容易被忽略的点是日志。高并发下每个业务接口都打info日志，不仅浪费磁盘，还会拖慢性能。日志必须分级：业务关键节点用info，调试信息用debug，并且上线环境要关闭debug日志。同时，日志采集不要同步刷盘，而是异步写入或交给专门的日志收集器（如Filebeat）。我曾有一次上线后，客户端反馈接口超时，结果发现是log日志每天产生200GB，磁盘IO打满导致的。所以，日志库的异步模式是必须开启的，同步写日志会让线程阻塞在IO上。总之，高并发优化不是一蹴而就的事，而是一个持续对抗、持续进化的过程。每一次压测、每一次监控报警、每一次线上故障，都是系统成长的养料。你永远无法设计出一个完美无缺的系统，但你一定能打造出一个既能承压又能快速恢复的弹性架构。