高并发是大型架构核心，下面我详解高并发系统压力@mikechen
数据库磁盘 I/O 瓶颈（最致命的短板）
在高并发写场景下，磁盘 I/O 几乎是 90% 系统的第一道红灯。
压力来源：随机写导致磁头频繁寻道，或是 WAL（预写日志）落盘频率过高。
优化手段：
读写分离/分库分表：物理分散 I/O 压力。
以顺序写代随机写：利用 LSM-Tree（如 RocksDB/HBase）结构。
缓存拦劫：在 DB 前挡一层 Redis，实现“写缓冲、读缓存”，确保 80% 的流量不直达硬盘。
锁竞争与内存瓶颈（系统并发度的天花板）
当多个线程争抢同一个资源时，系统的吞吐量会由于上下文切换（Context Switch）而大幅下降。
压力来源：
数据库行锁：高并发秒杀场景下的“热点更新”问题。
本地锁竞争：Java 中过多的 synchronized 或 ReentrantLock。
架构对策：
无锁化设计：利用 CAS（Compare And Swap）或者 Disrupter 环形队列。
分布式锁颗粒度优化：将热点数据拆分，例如将一个库存拆成 10 个分库。
CPU 瓶颈：算不过来 & 抢得太多
CPU 使用率长期接近 100%，平均负载持续高企，请求响应时间随并发上升而急剧变长，线程上下文切换频繁。
成因：
复杂计算、低效算法、循环嵌套多、无谓 JSON/对象转换等。
线程/协程过多，锁竞争激烈，导致频繁上下文切换，CPU 大量时间花在调度而不是干活上。
GC 压力大（如 JVM 堆过大、对象短命且多），导致 Stop-The-World 明显。
典型高并发风险：一旦 CPU 满载，接口延迟会随并发指数级上升。
进而触发重试、排队、超时，形成“雪崩”。
网络带宽与连接数瓶颈（被忽视的咽喉）
很多时候，服务器 CPU 还没满，系统就响应超时了，这通常是网卡或连接数满了。
压力来源：
带宽压满：大量静态资源（图片/JS）请求挤占了业务 API 的带宽。
连接数耗尽：Linux 系统的文件句柄数（ulimit）限制，或大量的 TIME_WAIT 状态连接导致无法建立新连接。
架构对策：
全量动静分离：如我们之前讨论的，静态资源必须走 CDN。
协议升级：使用 HTTP/2 或 QUIC 减少握手次数。
内核参数调优：优化 tcp_tw_reuse 和 tcp_max_syn_backlog。