数据库层面
- 索引规范：WHERE、JOIN、ORDER BY 字段必须建索引，但单表索引不超过 5 个，避免写操作变慢
- 慢查询治理：开启慢日志（阈值设为 1 秒），每周Review一次，全表扫描的 SQL 必须优化
- 连接池配置：MySQL 连接池建议设为 20-50（根据 CPU 核数调整），Redis 连接池不超过 100，避免把数据库压垮
缓存策略
- 热点数据缓存：QPS 超过 1000 的查询结果接入 Redis，过期时间设 10-30 分钟，并加随机值防止雪崩
- 防穿透设计：查询为空时缓存短时效空值（如 5 分钟），或用布隆过滤器拦截无效请求
- 缓存更新：先更新数据库，再删缓存，延迟双删策略处理极端并发
代码与架构
- 异步化：非核心逻辑（日志、短信、积分）扔 MQ（如 RocketMQ/RabbitMQ），接口 RT 控制在 200ms 内
- 批量操作：禁止 for 循环单条插入，改为批量（每批 500-1000 条），减少网络往返
- 限流熔断：核心接口限流（如 1000 QPS），依赖第三方服务加熔断（失败率超 50% 自动断开），防止拖垮主链路
稳定性保障
- 降级预案：大促期间可关闭非核心功能（如商品推荐、历史评价），优先保证下单支付
- 超时设置：所有 HTTP/RPC 调用必须设超时（建议 3 秒内），并提供默认降级数据，避免线程 hang 死
- 资源隔离：核心业务与后台任务分开部署，线程池独立配置，避免后台跑批影响实时交易
监控告警
- 黄金指标：监控 QPS、平均响应时间（P99<500ms）、错误率（<0.1%）、CPU/内存使用率（>80% 告警）
- 业务埋点：核心链路（如下单、支付）打印 traceId，失败立即钉钉/短信告警，5 分钟内响应
- 日志规范：只打印关键路径日志，ERROR 日志必须带上下文参数，避免磁盘打满
真实踩坑提示：生产环境最怕"隐形炸弹"，如定时任务半夜跑全表扫描、日志异步打印队列堆积、以及没设超时导致连接池被占满。建议每月做一次压测，用真实流量回放验证瓶颈。