高并发API的核心挑战
随着QPS的增长，API平台会依次遇到以下瓶颈：1000 QPS——数据库连接池可能不足；5000 QPS——单数据库实例CPU/IO打满；10000 QPS——单应用实例无法承载；50000 QPS——带宽和网络连接数成为瓶颈；100000+ QPS——需要全链路优化和水平扩展。
第一层：DNS + CDN流量分发
在用户访问的第一跳就进行分流。DNS智能解析可根据用户地理位置将流量分发到最近的机房。CDN用于缓存静态和准静态API响应，减少源站压力。这一层的目标是让尽可能多的请求在到达源站之前就被处理掉。
第二层：Nginx/负载均衡
Nginx是API平台最常用的流量入口。核心配置：worker_processes设置为CPU核心数、worker_connections设置足够的连接数（如65535）、upstream配置后端服务池并启用keepalive。使用至少2个Nginx实例 + Keepalived实现高可用。
第三层：应用服务层扩容
应用层应该设计为无状态（Session信息存储在Redis中），这样可以通过水平增加实例数量来线性提升处理能力。K8s的HPA（水平自动扩缩容）可以根据CPU/内存/QPS自动增减Pod数量，实现真正的弹性伸缩。
第四层：缓存层优化
Redis Cluster模式下，每个节点独立存储一部分数据，支持水平扩展。热点Key处理：多级缓存（本地Caffeine + Redis）+ 读写分离（主写从读）。缓存预热：系统启动时预加载热点数据到缓存，避免冷启动时大量请求穿透到数据库。
第五层：数据库分库分表
当单表数据量超过500万或写入QPS超过1000时，分库分表成为必经之路。常用方案：ShardingSphere-JDBC（应用层分片）、MyCat（中间件层分片）。分片键选择非常重要——应选择查询中最常用的字段（如tenant_id），避免跨分片查询。
第六层：异步与消息队列
不是所有请求都需要同步返回结果。使用消息队列（RocketMQ/Kafka/RabbitMQ）将非核心流程异步化——同步完成核心业务逻辑后立即返回，非核心逻辑（发短信、写日志、更新统计）异步处理。这能大幅降低API的响应时间。
高并发监控与弹性伸缩
高并发场景下的监控需要关注：实时QPS曲线（是否有突增/突降异常）、各层延迟分布（Nginx→App→Redis→DB各层耗时占比）、错误率趋势（是否接近限流阈值）、资源使用率（CPU/内存/网络/磁盘是否接近瓶颈）。基于这些指标配置弹性伸缩策略。