高并发

为什么尾延迟总是顽固 任务队列采用 FIFO 且缺少优先级隔离时，长任务会把短任务堵在后面，形成 head-of-line blocking。 设计要点 按任务类型分队列，避免互相干扰。 增加协作式抢占点，长任务主动让出。 对关键短任务设置高优先级通道。 指标建议 队列等待时长 p95/p99。 长短任务比值与切换频率。 任务被饿死次数。 小结 尾延迟是调度策略的直接结果。把任务分类、抢占点和优先级体系设计好，长尾才会真正收敛。

设计矛盾 异步日志通常在“吞吐、时延、可靠性”三角中权衡。默认无界队列最终会把内存打爆。 可靠性分级 关键审计日志：优先落盘成功，必要时阻塞。 普通诊断日志：可采样、可丢弃。 调试日志：高峰自动降级。 队列策略 多生产者单消费者 ring buffer。 明确 drop_oldest 或 drop_newest 语义。 将丢弃计数作为高优先级告警指标。 小结 先把日志等级与丢弃策略制度化，再谈性能优化。没有策略约束的异步日志，最后会反噬业务稳定性。

现象 某个 key QPS 极高，单分片 CPU 打满。 网络带宽与复制延迟在高峰突增。 迁移 slot 时业务抖动明显。 治理步骤 识别热点：按 key 维度打 sampling 访问日志。 评估可分片性：是否支持合并读、是否有排序依赖。 设计散列方案：hotkey:{uid}:N。 Go 读写示例 func shardKey(base string, uid int64, shards int) string { return fmt.Sprintf("%s:%d", base, uid%int64(shards)) } 写：按 shard 分散。 读：并发读取后聚合，必要时加本地短缓存。 额外策略 热点结果做二级缓存（进程内 + Redis）。 高峰期提前预热，避免瞬时击穿。 为热点接口配置独立限流与熔断。 小结 热点 key 的本质是负载不均。先把流量摊平，再谈更复杂的缓存一致性优化。