高可用与性能

高可用设计

• 服务降级：推送服务不可用时，只发站内信（用户打开 App 仍能看到）。
• 消息重试：推送失败自动重试 3 次。
• 监控告警：延迟、成功率、投诉监控。

降级的分级

推送可用：推送 + 站内信
推送故障：只站内信（降级，不丢）
都故障：消息入队，恢复后补发

降级的原则：核心体验（站内信）永不丢失，锦上添花（推送）尽力而为。

性能优化

• 批量操作：批量创建站内信，减少 IO。
• 异步处理：Celery 异步发送推送，不阻塞主流程。
• 连接池：HTTP 连接复用，避免频繁建连。

性能的瓶颈

通知系统的性能瓶颈通常不在业务逻辑，而在：

• 推送服务的吞吐（外部依赖）。
• 数据库写入（站内信批量创建）。
• 队列消费速率。

优化的顺序：先监控定位瓶颈，再针对性优化，而不是盲目加缓存。

一句话

高可用 = 降级（保站内信）+ 重试（不丢消息）+ 监控（发现问题）；性能 = 异步 + 批量 + 连接池。先看清瓶颈，再谈优化。