高并发系统设计

网络层：就近访问与流量清洗

在流量到达你的应用服务器之前，在网络边缘和网关层将其拦截或分流。

CDN 静态加速：将图片、JS、CSS、短视频甚至静态 HTML 页面缓存在距离用户最近的 CDN 节点，大约 80% 的流量在网络边缘就被消化了，不会穿透到核心机房。

负载均衡：利用 DNS 轮询、LVS（四层）以及 Nginx/HAProxy（七层）建立多级负载均衡体系，将流量均匀分发到后端的网关集群。

微服务网关：如 Spring Cloud Gateway 或 APISIX。在网关层完成鉴权、限流、路由、黑名单拦截，提前过滤掉非法或无效请求。

应用层：微服务化与异步化

应用层作为流量的直接入口，需要具备快速扩容和快速响应的能力。

无状态化与弹性扩容：将业务逻辑设计为无状态的，这意味着任何一个请求发送到哪台服务器处理都是一样的。这样可以通过增加机器（横向扩展，Scale-out）来分摊流量，结合 Kubernetes (K8s) 实现基于 CPU/内存利用率的自动弹性伸缩（HPA）。

异步化与解耦：将非核心的同步链路转为异步。引入消息队列（如 RocketMQ、Kafka），将“强一致性”改为“最终一致性”。

并发模型优化：采用非阻塞 I/O 模型（如 Netty 的 Reactor 模型），用极少的线程/进程切换开销换取数十万的高并发连接。

数据层：多级缓存与读写分离

高并发系统最终的瓶颈往往落在数据库（尤其是关系型数据库如 MySQL）上。因为磁盘 I/O 和行级锁是极其昂贵的。

多级缓存架构：

• 本地缓存：Guava Cache 或 Caffeine，直接驻留在应用内存中，速度最快，但需要注意多实例数据同步。
• 分布式缓存：Redis 支撑高达数十万的 QPS（每秒查询率）。将热点数据（如商品详情、用户 Token）放入 Redis。

读写分离：由于绝大多数互联网系统都是“读多写少”（如刷微博、看商品），采用主从架构（Master-Slave）。主库负责写，从库负责读，通过主从复制同步数据，成倍提升读性能。

分库分表：

• 垂直拆分：按业务把一个大数据库拆分成用户库、订单库、商品库。
• 水平拆分：当单表数据超过千万或行数过大导致索引变慢时，将一张表的数据按照某种规则（如 user_id % 64）分散到多个库、多张表中，打散 I/O 压力。

高可用“四大法宝”：防患于未然

当并发流量超出系统的最大承载能力时，必须采取自我保护机制，防止系统发生雪崩

限流：通过令牌桶或漏桶算法，限制单位时间内的请求量。对多余的流量直接拒绝（报错或返回繁忙提示），丢车保帅。

降级：当系统压力过大时，关闭非核心业务（如电商大促时关闭历史订单查询、关闭评价功能），将珍贵的计算资源留给核心链路（如支付、下单）。

熔断：当下游微服务因为高并发出现严重延迟或大量报错时，上游服务主动切断调用链路（类似保险丝），直接返回预设的默认值（Fallback），防止一个服务的崩溃拖垮整个调用链。

隔离：将资源进行物理或线程级的隔离。例如：核心业务和非核心业务使用不同的线程池；秒杀商品使用独立的 Redis 集群，防止单点故障波及全局。