流量暴涨

用户数突破百万之后，监控里数据库的 CPU 和 I/O 都冲到 85%，慢查询每天 500 多条，主库延迟 200ms。分析下来大部分请求是读、写却不多，单主库扛下了所有压力——这已经不是”再买台机器”能解决的，而是架构分工的问题。

这一章按四层推进。读写分离把读压力分流到从库，请求继续增长就再加从库。热点处理针对某个特别火的 API，搭起本地缓存、Redis、供应商 API 的多级缓存，再用热点 key 分散和本地缓存预热挡住瞬时洪峰。削峰填谷处理大活动期间流量暴增，用 RabbitMQ 把”接收请求”和”处理任务”解耦；代价是用户拿不到即时结果，得为任务状态查询、重试和失败提示另做设计。安全防护针对活动结束后的 DDoS：10 分钟 100 万次请求来自 5000 个不同 IP，CPU 打到 100%、数据库连接耗尽，只能靠网络层、应用层等多层防护挡在门外。

读完你应该能分辨一次压力到底该由读扩展、热点缓存、异步削峰还是流量防护来承接，也能为异步化方案设计用户看得见的状态与失败反馈。