面试题库

30 天从前端工程师到 Agent 工程师

D7 封装成服务：Fastify + SSE + Docker（dg P07）；W1 复盘

• 一个 SSE 长连接服务上线，心跳、连接断开处理和优雅退出分别在解决什么问题？For a long-lived SSE service in production, what problems do heartbeats, disconnect handling and graceful shutdown each solve?

  国内高频海外高频深入#sse#reliability#deployment

  分析过程 · 先想清楚再作答

  1. 这题的区分度在于三件事各自的失败现象完全不同，能分别说出现象的人一定真上过线。答成「都是为了稳定性」等于没答。
  2. 心跳解决的是「被中间设施误杀」。负载均衡和网关普遍有空闲超时，常见 60 到 120 秒，一段时间没有字节流动就关连接；而 Agent 天生有大量静默期——模型在思考、在调工具、在等慢接口。现象是连接莫名其妙断在一半，且本地直连时完全复现不了。实现上用 SSE 的注释行（冒号开头）做心跳，客户端会安静忽略，不用改客户端代码。
  3. 连接断开处理解决的是「花钱」。用户关掉页面之后服务端不会自动停，模型继续生成、token 继续计费，只是没人接收。这是流式服务里最贵的疏忽，而且测试环境暴露不出来，因为没人会中途关页面。做法是监听响应对象的关闭事件，判定是被掐断而不是正常收尾，就把上游请求一起中止。
  4. 这里有个必须说对的细节，说错会当场暴露没写过：Node 里要监听的是响应对象的 close，不是 request 的——request 的 close 在请求体读完时就触发，拿它当断线信号会把每一条正常请求都误判成客户端跑了，现象是每次只推出一两个片段就停。
  5. 优雅退出解决的是「发布时切断在途请求」。容器收到 SIGTERM 后应当先停止接受新连接，给在途的流一点收尾时间再退出，否则用户看到的是回复说了一半突然没了。前提是信号真的能传到进程——CMD 写成包管理器的话 PID 1 不是 node，SIGTERM 传不到，只能等超时被强杀。
  6. 可以预期的追问：收尾时间给多久？答案是要小于编排系统的终止宽限期（Docker 默认十秒、K8s 默认三十秒），超过就会被 SIGKILL，等于白设计；同时新连接要立刻拒绝，让负载均衡把流量挪走。

  How to reason about it · think before answering

  1. The discriminator is that the three have completely different failure symptoms. Someone who can describe each symptom has shipped one; 'they all improve stability' is a non-answer.
  2. Heartbeats prevent middleboxes from killing you. Load balancers and gateways commonly close idle connections after 60 to 120 seconds, and agents are full of silent gaps while the model reasons, calls a tool or waits on a slow API. The symptom is a stream that dies halfway for no visible reason and never reproduces against a local server. Implement it as an SSE comment line, which clients silently ignore, so no client change is needed.
  3. Disconnect handling is about money. When a user closes the tab the server does not stop on its own: the model keeps generating and tokens keep billing with nobody receiving. It is the most expensive oversight in streaming services, and staging never reveals it because nobody closes tabs mid-run. Watch for the response closing, distinguish a premature close from a normal finish, and abort the upstream request.
  4. One detail must be right or it exposes you immediately: in Node listen on the response object's close, not the request's. The request emits close once its body has been read, so using it as a disconnect signal misfires on every normal request and you see streams stopping after one or two chunks.
  5. Graceful shutdown is about deploys cutting live requests. On SIGTERM the process should stop accepting new connections, give in-flight streams a short window, then exit; otherwise users watch a reply stop mid-sentence. This assumes the signal actually reaches the process — if the container's PID 1 is a package manager, SIGTERM never arrives and the runtime kills you on timeout.
  6. Expect: how long is the window? Shorter than the orchestrator's termination grace period (10s by default in Docker, 30s in Kubernetes), or you get SIGKILLed anyway; and refuse new connections immediately so the load balancer drains traffic away.

  答题要点

  • 心跳防的是中间设施的空闲超时，Agent 的静默期常常超过网关的 60 到 120 秒，用 SSE 注释行实现，客户端无感
  • 断开处理防的是浪费：用户关页面后服务端不停就是纯烧 token，测试环境暴露不出来
  • Node 里要监听响应对象的 close 而不是 request 的——后者在请求体读完时就触发，会把正常请求误判成断线
  • 优雅退出防的是发布切断在途流：SIGTERM 后先停收新连接、给在途流收尾时间，收尾窗口要小于编排系统的终止宽限期
  • 前提是信号能传到进程：容器的 PID 1 必须是 node 本身，不能是包管理器

  Key points

  • Heartbeats defeat idle timeouts in middleboxes, since agent silence often exceeds a gateway's 60 to 120 seconds; SSE comment lines do it transparently
  • Disconnect handling stops waste: after a user closes the tab, an unaware server keeps burning tokens, and staging never shows it
  • In Node listen on the response's close, not the request's — the latter fires when the body is read and misclassifies normal requests as disconnects
  • Graceful shutdown stops deploys from cutting live streams: on SIGTERM refuse new connections and drain, within the orchestrator's grace period
  • It only works if the signal reaches the process, so PID 1 must be node itself rather than a package manager

D11 run 状态机、输出流回传、按 runId 保序、SSE 等待者、30s 打断合并

• 流式接口的客户端断线重连后，怎么做到既不丢片段也不重复？After a streaming client reconnects, how do you deliver every missed chunk exactly once — no gaps, no duplicates?

  国内高频海外高频深入#sse#idempotency#reconnect

  分析过程 · 先想清楚再作答

  1. 「不丢」和「不重复」要分开答。只答一半的人很多：说了从库里补发（不丢），却没说重叠部分怎么去重（不重复）。
  2. 推导链很短：客户端知道自己最后收到的编号 → 它重连时把这个编号带回来 → 服务端从下一号开始给 → 前提是编号连续不跳号。所以能不能重连，取决于当初有没有把序号设计成从 0 开始、连续、单调。序号一旦是时间戳或随机 id，这条链第一步就断了。
  3. 然后给三步实现和各自的坑：第一步换算，带回来的是「最后收到」的那一号，要加一，少加一重复一帧、多加一丢一个字，这是整段逻辑里唯一的算术也最常写错；第二步先从持久化里回放缺的部分，因为库里一定是全的；第三步再接上还在流动的那条流，两边必然重叠，靠「小于当前指针的一律丢弃」去重——幂等回放的全部秘密就是这一次比较。
  4. 这里要点出为什么必须双写：片段既进流也进库。只有流，重连时早期片段已被消费掉；只有库，就得轮询查库，首字延迟从几十毫秒涨到几百毫秒。代价是写放大，一次回答几百个片段就是几百行，生产里按批落库（每几十个片段或每两百毫秒一次）。
  5. 对齐一下协议细节：浏览器原生的事件源会自动把上次的编号放进重连请求头带回来；但大模型接口通常要用 POST，原生事件源只能发 GET，所以真实前端多是手写解析，重连时要自己把编号带上——这个细节能证明你真接过前端。
  6. 可以预期的追问：回放要保留多久？必须给两个边界——保留期（逐片段的行只对最近若干小时的执行保留，之后归档成一整条完整回复并删掉碎行）和回放上限（一次重连最多回放多少片段，超了就一次性发完整文本而不是逐字重演）。不定这两条，那张表会变成全库最大且 99% 的行写完十秒后再没人读。

  How to reason about it · think before answering

  1. Answer 'no gaps' and 'no duplicates' separately. Plenty of candidates cover only the first — they backfill from storage but never say how the overlap is deduplicated.
  2. The chain is short: the client knows the last id it received, it sends that id back on reconnect, the server resumes from the next one — and all of that requires contiguous, monotonic numbering. Whether resumption is possible at all was decided when you chose the sequence scheme; timestamps or random ids break the chain at step one.
  3. Then the three steps and their individual traps. Convert: the client reports the last id it *received*, so add one — off by minus one repeats a frame, off by plus one drops a character, and this is the only arithmetic in the whole flow and the most commonly wrong line. Replay: read the missing range from durable storage, which is always complete. Attach: resume the live stream, whose overlap with the replay is guaranteed, and drop anything below the cursor. That single comparison is all there is to idempotent replay.
  4. Explain why the dual write is mandatory: chunks go both to the stream and to the table. Stream only, and the early chunks are gone by reconnect time; table only, and you are polling the database, pushing time-to-first-token from tens to hundreds of milliseconds. The cost is write amplification — hundreds of rows per answer — so production batches the writes, every few dozen chunks or every couple hundred milliseconds.
  5. Get the protocol detail right: the browser's native event source replays the last id in a request header for you, but model endpoints generally need POST while that API only issues GET, so real frontends hand-roll the parser and must resend the id themselves. Mentioning this proves you have actually wired up the client side.
  6. Expect: how long do you keep replayable data? Give two bounds — a retention window (per-chunk rows only for runs from the last few hours, then collapsed into one complete message) and a replay cap (beyond N chunks, send the full text once instead of re-enacting it character by character). Without both, that table becomes the largest in the database while 99% of its rows are never read again after ten seconds.

  答题要点

  • 重连的前提是序号从 0 开始、连续、单调；序号是时间戳或随机 id 就无法续传
  • 客户端带回来的是「最后收到」的那一号，服务端要加一再开始，这是唯一的算术也最容易错
  • 先从库里回放缺的片段（库一定是全的），再接上还在流动的流，重叠部分靠「小于当前指针一律丢弃」去重
  • 片段必须双写：流服务当前挂着的连接，库服务等一下才回来的人；代价是写放大，生产里按批落库
  • 必须定保留期与回放上限：过期的执行归档成一整条完整回复，超长回放直接一次性发完整文本

  Key points

  • Resumption requires a contiguous, monotonic sequence starting at 0; timestamps or random ids make it impossible
  • The client reports its last received id, so the server resumes from that id plus one — the single most error-prone line
  • Replay the gap from durable storage first, then attach the live stream, discarding anything below the cursor to dedupe the overlap
  • Dual-write every chunk: the stream serves currently attached connections, the table serves clients that come back later; batch the writes in production
  • Set a retention window and a replay cap — archive old runs into one complete message and send full text instead of re-enacting long replays