高可用系统复盘：用日志、指标和调用链还原故障

高可用系统复盘用日志、指标和调用链还原故障故障复盘不是写一篇故事而是还原时间线和因果证据。发布变更、指标拐点、日志样本与 Trace 应能相互对齐没有证据的推断标为待验证。这样留下的改进项才可验收。故障定位证据链日志、Metrics 与 Trace 的交叉验证复盘先整理可核对的时间线。讨论出现分歧时回到发布记录、指标原始值、日志样本和 Trace不用结论性形容词替代证据。对于调用链较长的系统应把指标Metrics、链路Trace与日志Logs放到同一时间轴并保留原始查询链接与数据版本方便复核。可以按下面三类证据组织复盘材料证据一Metrics 指标异常证据二Trace 链路断点{ trace_id: a4f89b21e09c4d12, span_id: c789123a, name: Redis Exec Lua Script, duration_us: 8501230, attributes: { db.system: redis, db.statement: EVALSHA 4a9bc811..., error: true, error.kind: CommandTimeoutException } }证据三底层慢日志证据在 Redis Cluster 侧拉取SLOWLOG GET 10证据锤实1) 1) (integer) 4821 2) (integer) 1757372401 3) (integer) 1250000 # 执行耗时 1.25 秒 4) 1) EVALSHA 2) 4a9bc81123... 3) 1 4) lock:order:sku_89123KEYS *会在线性扫描期间占用 Redis 主线程数据量越大其他请求等待得越久。不要预设会积压多少连接应用LATENCY DOCTOR、SLOWLOG和网关连接数共同确认阻塞是否向上游扩散。从漏洞到防护代码与架构级别的落地改进复盘不能停留在“以后注意”这类表态上。每个已验证原因都要对应具体改动、责任人、验收方式和复查日期。针对 Lua 脚本阻塞与 Redis 命令滥用可以在架构层引入两项物理硬约束禁用所有不带LIMIT或含有KEYS/FLUSHALL的命令在 CI/CD 静态代码扫描中增加 AST 规则拦截。对所有的分布式锁与 Redis Lua 脚本调用强制封装硬超时机制与降级兜底路径。优化后的分布式锁操作封装代码package com.architecture.highavailability.lock; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.data.redis.core.script.DefaultRedisScript; import java.util.Collections; import java.util.concurrent.*; public class SafeDistributedLock { private static final Logger log LoggerFactory.getLogger(SafeDistributedLock.class); private final StringRedisTemplate redisTemplate; // 独立设立执行线程池隔离 Redis 阻塞风险 private final ExecutorService lockExecutor new ThreadPoolExecutor( 8, 32, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(1000), new ThreadPoolExecutor.DiscardPolicy() ); public SafeDistributedLock(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } public boolean acquireLockWithHardTimeout(String lockKey, String requestId, int expireSeconds, long timeoutMillis) { FutureBoolean future lockExecutor.submit(() - { String script if redis.call(set, KEYS[1], ARGV[1], NX, EX, ARGV[2]) then return 1 else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result redisTemplate.execute(redisScript, Collections.singletonList(lockKey), requestId, String.valueOf(expireSeconds)); return Long.valueOf(1L).equals(result); }); try { // 物理限制最长等待耗时超期直接强行放弃争抢并降级 return future.get(timeoutMillis, TimeUnit.MILLISECONDS); } catch (TimeoutException e) { log.error([ALERT] 锁争抢强行超时中断, LockKey: {}, 等待上限: {}ms, lockKey, timeoutMillis); future.cancel(true); return false; // 返回 false 走业务降级分支 } catch (Exception e) { log.error([ERROR] Redis 锁执行异常, Key: {}, lockKey, e); return false; } } }故障复盘产出物清单一次合格的复盘最终应落盘为以下四项具体产出缺一不可产出物类别改进内容细节验收标准与落地责任人代码规则库 (Lint Rules)增加 Sonar/ArchUnit 自定义规则禁止在业务层直接调用eval未审查的 Lua 脚本CI 编译流程自动拦截并阻断 Build监控面板 (Grafana)增加 Redis 延迟、阻塞命令与连接等待面板指标可按 Trace 时间窗交叉查询指定维护人预案手册 (Runbook)写明 Redis 异常时的降级条件、操作与回滚演练人员能按步骤执行并恢复指定维护人故障演练 (Chaos Eng)注入 Redis 延迟与命令超时告警、降级和恢复均留下时间戳指定复查日期总结对待故障的态度决定系统的上限复盘的终点是“系统韧性Resilience的提升”。高可用不等于不会故障。每次复盘都应留下可验证的改进项例如新增告警、调整超时或补充回滚演练并在约定日期复查。