用户增长

用户数突破千级之后，单机开始吃力：某天下午收到 P1 告警，CPU 95%、内存 85%、响应时间 500ms+，慢查询每天 500 多条，数据库连接也开始紧张。问题从”能不能跑”变成了”能不能扛住”。

这一章处理四件事。先做容量分析，把 CPU、内存和数据库连接的瓶颈逐个定位；再引入负载均衡，把请求分发到多台实例，比较轮询、最少连接、IP 哈希和加权轮询的差别，配上健康检查与会话保持；接着是限流，先用固定窗口、滑动窗口和令牌桶三种算法定下放行规则，再把限流中间件落到 API 层；最后还要回头补上分布式限流——单机时代那套 Redis 计数，在多实例并发下会因竞态而漏扣令牌。

此外还有调用量统计：运营要按用户、时段、接口看到用量，为的是后面的套餐和计费。做法是预聚合，实时更新统计结果、定期聚合原始日志、查询时直接读统计表，原始日志则按计划清理。

读完你应该能解释”为什么上了多台机器之后限流反而失效”，能独立选型负载均衡策略与限流算法，并说清它们各自解决了哪个阶段的什么问题。