终局复习：从一条请求到生产故障闭环

为什么终局复习不能再列一遍组件名

会说 RAII、GDB、mutex、epoll、tcpdump、TLV、Reactor、Redis ae 和 heartbeat，不等于能解释一次故障。综合能力要求你在同一时间线上回答：谁拥有状态、输入是什么、调用后状态怎样变化、失败会留下什么证据、下一层如何恢复。

先预测：一次 HTTP/TLV request 在 decoder 之后进入 worker，connection 却在 result 返回前关闭；哪些 chapter contracts 能阻止 result 写到复用 fd？沿下图逐段检查 owner/evidence。

第一关：C++ 对象与调试证据

第 1 章要求 RAII object 的 destructor 闭合 fd/thread/buffer ownership，shared_ptr/weak_ptr 边界不形成 cycle；第 2 章要求 core、binary、symbols、source revision 与 build-id 完全匹配。没有 object lifetime，就无法判断 use-after-free；没有 artifact identity，stack line 也不可信。

Object owner graph: Service → EventLoops → Connections → Buffers/Timers
Artifact chain: commit → flags → binary/build-id → symbols → core/stack

第二关：thread happens-before 与 socket state

第 3 章把 thread start/ready/stop/join、mutex/condition/atomic 与 bounded pool 写成 happens-before；第 4 章把 connect pending、partial I/O、would-block、FIN、EINTR 与 SIGPIPE 写成 socket state。两章共同保证“并发执行”不会丢失 bytes 或 lifetime。

worker.submit([request, weak = connection.weak_handle()] {
  Result result = execute(request);
  owner_loop.post([weak, result = std::move(result)]() mutable {
    if (auto connection = weak.lock_current_generation()) {
      connection->send(std::move(result));
    }
  });
});

如果 worker 直接 send，mutex 也无法解决 fd reuse、partial offset 和 interest mask。single-loop owner 是 concurrency 与 network 两章的交汇点。

第三关：故障证据与协议边界

第 5 章从 interface/route/ICMP/port/socket/PID/app 到 packet 逐层证伪；第 6 章从 arbitrary recv chunks 增量解析 length/TLV/HTTP/WebSocket，并限制 length/version/compression。故障取证必须同时问“wire 上到达哪些 bytes”和“parser 当前消费到哪”。

tcpdump: seq=1000 len=6  → input buffer [header + 2 body bytes]
tcpdump: seq=1006 len=8  → input buffer completes frame + next header
decoder: qb/read offset  → dispatch exactly one frame, retain suffix

第四关：单服务结构与 Redis 源码证据

第 7 章把 Poller/EventLoop/Connection/Buffer/Codec/Session/Timer/worker queue 组成 single-owner service；第 8 章用 Redis 6.0 验证真实调用链：initServer → acceptTcpHandler → createClient → readQueryFromClient → processInputBuffer → addReply/writeToClient → freeClient。

Redis threaded I/O 提醒我们不要用线程名推断 ownership：socket reads/writes 可由 I/O workers 批处理，parser/command/keyspace owner 仍需按 6.0 具体函数阶段证明。

第五关：恢复、心跳与可观测性

第 9 章让 disconnect reason 进入 reconnect classification/backoff，让 heartbeat seq/miss 进入 liveness state，让 logs/error/metrics/monitoring port 使用相同 correlation identity。恢复不是 reconnect 成功就结束，还要重新认证/协商/恢复 session，并处理 uncertain writes。

disconnect(reason=timeout, connection_id=42)
  → heartbeat misses + packet/socket evidence
  → reconnect attempt/jitter/deadline
  → auth/version/session restore
  → ready=true + correlated metrics/logs

五类事故的跨章定位

发布前九项综合验收

本章回顾：九章最终汇成三条线

1. Owner 线：RAII/thread/EventLoop/Connection/client/reconnect timer 确定谁修改和释放状态。
2. State 线：socket/parser/service/recovery 的每个返回值都进入明确下一状态。
3. Evidence 线：build-id/GDB/socket/packet/parser/queue/log/metrics 在同一时间和 identity 下互相印证。
4. Redis 源码是机制验证，不是孤立阅读；第 9 章是生产闭环，不是附加工具。
5. 九项 production gates 全部有自动化证据，才完成本书验收。

术语表