面试题库

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

D8 为什么 Gateway/Worker 分离；Postgres 表设计（sessions/runs/messages）+ Drizzle

• 什么是无状态服务？它对水平扩展意味着什么？Worker 算不算有状态？What makes a service stateless, what does that mean for horizontal scaling, and are workers stateful?

  国内高频海外高频进阶#stateless#scalability

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

  1. 这题的陷阱是字面理解。很多人答成「不保存任何数据」，那是错的——无状态服务当然会写数据库。区分度在于你能不能给出准确定义。
  2. 准确定义只有一句：无状态指的是**状态不留在处理请求的那个进程身上**，因此任意一台实例都能处理任意一个请求。把它翻译成一个自检问题就很好用：随便杀掉一台实例，有没有任何用户的数据只存在于那台机器上？答「没有」才是无状态。
  3. 再推出水平扩展的三个后果：新实例不需要预热或同步数据，接上负载均衡立刻能干活；任意实例可以随时被杀，滚动发布和抢占式实例才成立；不需要会话粘连，而粘连一旦存在，扩容时的重新分配就会打断老用户的会话。
  4. Worker 那一问要答得有分寸：它持有的不是用户数据，而是一次执行的进度（跑到第几轮、调了哪些工具、后面还会加上一个租约）。用户数据始终在数据库里。所以说它有状态，指的是「手上有活没交代完」，后果是不能随便杀——必须优雅停机，先拒绝新任务再等手头的跑完。
  5. 可以预期的追问：内存缓存算不算破坏了无状态？答案是看丢了会不会出错。纯粹用于加速、丢了只是变慢的缓存不破坏无状态；一旦某个用户的会话只存在于某台机器的内存里，你就已经在偷偷依赖粘连了，扩容那天必然出事。

  How to reason about it · think before answering

  1. The trap is reading the word literally. Many candidates say 'it stores nothing', which is wrong — stateless services write to databases all day. The discriminator is whether you can define it precisely.
  2. One sentence does it: stateless means state does not live in the process handling the request, so any instance can serve any request. Turn it into a self-check: kill a random instance — does any user's data exist only there? Only 'no' is stateless.
  3. Derive three scaling consequences: a new instance needs no warm-up or data sync and starts serving the moment it joins the load balancer; any instance can be killed at will, which is what makes rolling deploys and spot instances viable; and no sticky sessions are needed, whereas stickiness means rebalancing during a scale-up cuts existing conversations.
  4. Answer the worker half carefully: it holds execution progress, not user data — which turn it is on, which tools it called, and later a lease. User data always lives in the database. So 'stateful' here means 'holding unfinished work', and the consequence is that you cannot kill it freely: drain first, refuse new work, let the current run finish.
  5. Expect the follow-up: does an in-memory cache break statelessness? It depends on whether losing it causes wrong behavior. A pure accelerator that only costs latency is fine; the moment a user's session exists only in one machine's memory you are silently relying on stickiness, and the next scale-up will prove it.

  答题要点

  • 无状态的准确含义是状态不留在处理请求的进程里，任意实例都能处理任意请求，而不是「不存数据」
  • 自检方法：随便杀一台实例，是否有用户的数据只存在于那一台上
  • 水平扩展的三个前提：新实例无需预热、任意实例可被随时杀掉、不需要会话粘连
  • Worker 的有状态指的是持有一次执行的进度而不是用户数据，后果是必须优雅停机而不能随便杀
  • 只加速、丢失只降速的缓存不破坏无状态；承载唯一副本的内存数据等于隐式的会话粘连

  Key points

  • Stateless means the state does not live in the request-handling process, so any instance serves any request — not that nothing is stored
  • Self-check: kill any instance and ask whether any user's data existed only there
  • Three scaling prerequisites: no warm-up, any instance disposable, no sticky sessions
  • Workers are stateful in the sense of holding run progress, not user data, so they need graceful drain rather than a hard kill
  • A pure accelerator cache is fine; in-memory data that is the only copy is implicit stickiness
• sessions / runs / messages 这三张表你会怎么设计主键与索引？为什么不用自增主键？How would you design primary keys and indexes for sessions, runs and messages, and why avoid auto-increment ids?

  国内高频海外高频进阶#database#schema-design#idempotency

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

  1. 这题看着像八股，其实每一个选择背后都有一个具体约束。判断标准是：你能不能为每个决定说出「不这么做会发生什么」。
  2. 先讲为什么是三张表而不是一张：粒度不同。会话是长期容器，一次执行有生命周期且可能失败重来，消息是不可变事实。少了「一次执行」这一层，你就没有地方回答「这次跑完没有」「该不该重试」「这轮花了多少钱」。
  3. 主键选文本型的应用侧 id（UUID 或 ULID），理由是接入层必须在写库之前就把 id 放进 202 响应体返回给客户端；自增主键要等数据库插完才知道值，那次往返就被卡在用户的等待路径上，而且多实例无法预分配。附带好处是将来分库分表不用重编号。
  4. 索引按查询路径建，不按直觉建：按用户拉会话列表要 sessions 的 user_id 索引，按会话拉历史要 messages 的 session_id 索引，外键列本身要索引否则删除父行会全表扫。多余的索引不是免费的，每个都让写入变慢。
  5. 两条唯一约束才是这套设计的灵魂：runs 的幂等键唯一，挡住重复投递；messages 的「run id 加序号」复合唯一，既保证同一次执行的输出顺序稳定，又让断线重连可以按序号幂等回放。序号要从 0 开始、连续、不跳号，否则续传就找不到断点。
  6. 可以预期的追问：ULID 和 UUIDv4 选哪个？答 ULID 或 UUIDv7——它们按时间有序，插入时集中在 B 树右端，不像 UUIDv4 那样随机分布导致页分裂和缓存命中率下降。这个细节能直接体现你关心过写入性能。

  How to reason about it · think before answering

  1. It looks like a trivia question, but every choice sits on a concrete constraint. The test is whether you can say what breaks if you choose otherwise.
  2. Start with why three tables rather than one: the grains differ. A session is a long-lived container, a run has a lifecycle and can fail and be retried, a message is an immutable fact. Without the run layer there is nowhere to answer 'did this finish', 'should we retry', or 'what did this turn cost'.
  3. Use text primary keys generated in the application (UUID or ULID), because the gateway must put the id into the 202 response before the row is written. Auto-increment ids are only known after the insert, which parks a round trip in the user's wait path and cannot be pre-allocated across instances. A bonus is that sharding later needs no renumbering.
  4. Index by query path, not by instinct: sessions need an index on user_id to list a user's conversations, messages need one on session_id to load history, and foreign key columns need indexes or deleting a parent row triggers a full scan. Extra indexes are not free — each one slows writes.
  5. The two unique constraints carry the design: a unique idempotency key on runs blocks duplicate delivery, and a composite unique on run id plus sequence in messages both fixes output ordering for one run and lets a reconnect replay idempotently by sequence. The sequence must start at zero and never skip, otherwise resume cannot find the cut point.
  6. Expect the follow-up: ULID or UUIDv4? Choose ULID or UUIDv7 — they are time-ordered so inserts land at the right edge of the B-tree, whereas random UUIDv4 scatters writes, splits pages and hurts cache hit rates. Mentioning this shows you have watched write performance.

  答题要点

  • 三张表对应三种粒度：会话是长期容器、run 是一次有生命周期的执行、message 是不可变事实；少了 run 就无法回答是否跑完、该不该重试、花了多少钱
  • 主键用应用侧生成的文本 id，因为 Gateway 要在写库之前把 runId 放进 202 响应里，自增主键必须等插入完成且无法跨实例预分配
  • 索引按实际查询路径建：sessions 的 user_id、messages 的 session_id、以及外键列；多余索引会拖慢写入
  • 两条唯一约束是灵魂：runs 的幂等键唯一挡重复投递，messages 的「run id 加序号」复合唯一保证保序与幂等回放
  • id 优先选 ULID 或 UUIDv7 这类时间有序的方案，避免随机 UUID 造成的页分裂与缓存失效

  Key points

  • Three tables for three grains: a long-lived session, a run with a lifecycle, and immutable messages; without runs you cannot answer completion, retry or cost questions
  • Application-generated text ids, because the gateway must return the run id in the 202 before the write, and auto-increment ids cannot be pre-allocated across instances
  • Index the real query paths — user_id on sessions, session_id on messages, plus foreign key columns; extra indexes slow writes
  • Two unique constraints carry the design: a unique idempotency key on runs, and a composite unique on run id plus sequence in messages for ordering and idempotent replay
  • Prefer time-ordered ids such as ULID or UUIDv7 over random UUIDv4 to avoid page splits and cache misses

D9 Redis Streams 消息总线：XADD/XREADGROUP/XACK/XAUTOCLAIM、consumer group、毒消息

• XACK 和 XAUTOCLAIM 分别解决什么问题？XACK 放在业务处理之前和之后有什么区别？What problems do XACK and XAUTOCLAIM each solve, and what changes if you XACK before instead of after doing the work?

  国内高频海外高频进阶#message-bus#redis-streams#error-handling

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

  1. 题眼在后半句。前半句背文档就能答，后半句在考你知不知道 ack 的时机直接决定了整个系统的投递语义——答不出这一点，面试官会判定你没在生产里管过队列。
  2. 先把两个命令的分工说清：XACK 是「销号」，把消息从 pending 清单里删掉，代表这件事真的做完了；XAUTOCLAIM 是「接手」，把闲置超过阈值的 pending 消息改判给另一个消费者，代表原来那个人可能已经死了。一个负责正常收尾，一个负责异常兜底。
  3. 然后回答时机问题，用一句话定性：先 ack 再干活是 at-most-once，先干活再 ack 是 at-least-once。前者进程一崩消息就人间蒸发，pending 清单里查不到、XAUTOCLAIM 也捡不回来；后者最坏是重复执行，而重复可以用幂等挡掉，丢单挡不掉。所以除了埋点日志这类丢一条无所谓的场景，一律先干活再 ack。
  4. 补一个大多数人漏掉的点：处理失败时正确的动作是**什么都不做**，让消息留在 pending 里等 XAUTOCLAIM。很多人会在 catch 里顺手 ack 掉，那等于把失败的消息静默丢弃，比不重试更糟——因为你连丢了什么都不知道。
  5. 再补一条 XAUTOCLAIM 的参数取舍：空闲阈值要大于「一次正常处理的耗时上限」。给太小会把还在正常处理的消息抢走，同一件事被跑两遍；给太大则故障恢复变慢。但要说清，调大阈值只降低重复概率，不消灭重复，兜底始终是消费端的唯一约束。
  6. 可以预期的追问：为什么用 XAUTOCLAIM 而不是 XCLAIM？答：XCLAIM 要你先 XPENDING 查出候选 id 再点名认领，两步之间还有竞态；XAUTOCLAIM 自己扫 pending 并返回游标，一条命令搞定，是 Redis 6.2 之后的推荐做法。

  How to reason about it · think before answering

  1. The hinge is the second half. The first half is documentation; the second asks whether you know that ack timing decides the delivery semantics of the whole system.
  2. Split the two commands: XACK clears a message from the pending list, meaning the work is genuinely finished; XAUTOCLAIM reassigns a pending message that has been idle past a threshold, meaning its previous owner may be dead. One is the normal path, the other is the failure path.
  3. Then answer the timing question categorically: ack-then-work is at-most-once, work-then-ack is at-least-once. In the first, a crash makes the message vanish — it is not in the pending list, so XAUTOCLAIM cannot recover it. In the second, the worst case is duplicate execution, and duplicates can be blocked by idempotency while lost work cannot. Always work first, except for fire-and-forget telemetry.
  4. Add the point most people miss: on failure the correct action is to do nothing and leave the message pending for XAUTOCLAIM. Acking inside the catch block silently discards failures, which is worse than no retry because you no longer know what you lost.
  5. Add the parameter trade-off: the idle threshold must exceed the worst-case normal processing time. Too small and a healthy in-flight message gets stolen and executed twice; too large and recovery is slow. Be explicit that tuning it only lowers the probability of duplicates — the real backstop is a uniqueness constraint on the consumer side.
  6. Expect: why XAUTOCLAIM rather than XCLAIM? XCLAIM needs an XPENDING scan first and then a named claim, with a race in between; XAUTOCLAIM scans and returns a cursor in one command, and is the recommended approach since Redis 6.2.

  答题要点

  • XACK 负责正常收尾：把消息从 pending 清单里销号，代表这件事真的做完了；重复 ack 返回 0，天生幂等
  • XAUTOCLAIM 负责异常兜底：把闲置超过阈值的 pending 消息改判给另一个消费者，解决「消费者死了它手上的消息怎么办」
  • 先 ack 再干活是 at-most-once，崩溃就丢单；先干活再 ack 是 at-least-once，最坏是重复，可以用幂等挡
  • 处理失败时不要 ack，让消息留在 pending 里等接手；在 catch 里顺手 ack 等于静默丢弃失败
  • 空闲阈值要大于正常处理耗时的上限，但调大只降低重复概率，兜底仍是消费端唯一约束

  Key points

  • XACK is the happy-path close-out: it clears the message from the pending list; repeat acks return 0, so it is naturally idempotent
  • XAUTOCLAIM is the failure backstop: it reassigns pending messages idle past a threshold, answering 'what happens to work held by a dead consumer'
  • Ack-before-work is at-most-once and loses work on a crash; work-before-ack is at-least-once and at worst duplicates, which idempotency can absorb
  • Never ack on failure — leave the message pending for takeover; acking in the catch block silently discards failures
  • The idle threshold should exceed worst-case processing time, but tuning it only reduces duplicates; uniqueness constraints are the real guarantee
• Redis Streams 和 Kafka 该怎么选？什么情况下 Streams 明显不够用？How do you choose between Redis Streams and Kafka, and when is Streams clearly not enough?

  国内高频海外高频进阶#message-bus#redis-streams#architecture

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

  1. 这题的坏答案是「看数据量」。吞吐从来不是第一判据——单机 Redis 每秒几万条 XADD 毫无压力，绝大多数业务的量级根本碰不到天花板。答成「量小用 Streams、量大用 Kafka」会被认为没做过选型。
  2. 换成两个真正的判据来推：一、这些消息需要保留多久；二、会不会有第二类消费方。生命周期是「执行一次就没用了」、且只有执行层这一个消费方，Streams 完全够用，还省掉一整套运维；需要「三个月内任意时间点重放」、或者同一份数据要同时喂给实时执行、离线数仓、风控三条链路，那就该上 Kafka。
  3. 再补三条结构性差异：Streams 是内存为主、保留全靠你自己 MAXLEN 或 XTRIM，Kafka 是磁盘顺序写、保留几周是常态；Streams 一个组里加多少消费者都行，Kafka 的消费者数受分区数限制，多了就有人空转；顺序保证的粒度不同，Streams 是单条流内有序而组内分配随机，Kafka 是同 key 落同分区、分区内有序。
  4. 然后主动说出那条最能体现深度的话：Redis 的持久化是有损的。AOF 默认每秒刷盘，最坏丢最后一秒的写入；主从异步复制，故障切换时未同步的消息会消失。所以用 Streams 时架构上必须有一个真相之源——本课是 Postgres 的 runs 表，流只是触发器，丢了消息那个 run 还停在 pending，补投任务会把它捡回来。把总线当唯一数据源是最危险的误用。
  5. 结论落成一句可复用的判断：Streams 适合「触发执行」，Kafka 适合「数据管道」。前者的消息是一次性的命令，后者的消息是需要被多方反复读取的事实。
  6. 可以预期的追问：那 RabbitMQ、SQS 呢？答：RabbitMQ 强在复杂路由和延迟队列（Streams 没有原生延迟投递，要自己带「下次可执行时间」重投）；SQS 强在零运维，代价是没有回放、也没有严格顺序（FIFO 队列另算）。把判据说成「保留时长、消费方数量、路由复杂度、运维预算」四条，比背产品参数强得多。

  How to reason about it · think before answering

  1. The bad answer is 'it depends on volume'. Throughput is never the first criterion — a single Redis node handles tens of thousands of XADDs per second, and most workloads never approach that ceiling. 'Small volume Streams, large volume Kafka' reads as never having run a real evaluation.
  2. Use two real criteria instead: how long the messages must be retained, and whether a second class of consumer will appear. If a message is useless once executed and the execution layer is the only consumer, Streams is plenty and saves an entire operational surface. If you need replay from any point in the last three months, or the same data must feed real-time execution, an offline warehouse and a risk engine, choose Kafka.
  3. Add three structural differences: Streams is memory-first with retention you enforce yourself via MAXLEN or XTRIM, while Kafka does sequential disk writes and keeps weeks by default; a Streams group takes any number of consumers, while Kafka consumers are capped by partition count and extras idle; ordering granularity differs — Streams orders a single stream but dispatches randomly within a group, Kafka pins a key to a partition and orders within it.
  4. Then volunteer the line that shows real depth: Redis persistence is lossy. AOF fsyncs once per second by default, so the last second of writes can vanish, and replication is asynchronous, so a failover can drop unreplicated messages. Using Streams therefore requires a source of truth elsewhere — here the Postgres runs table, with the stream acting only as a trigger; a lost message leaves the run pending and a sweeper republishes it. Treating the bus as the only datastore is the dangerous misuse.
  5. Land on a reusable rule: Streams suits triggering work, Kafka suits data pipelines. One carries one-shot commands, the other carries facts that many parties re-read.
  6. Expect: what about RabbitMQ or SQS? RabbitMQ wins on complex routing and delayed delivery (Streams has no native delay, you republish with a next-eligible timestamp); SQS wins on zero operations at the cost of replay and strict ordering (FIFO queues aside). Framing the criteria as retention, number of consumers, routing complexity and operational budget beats reciting product specs.

  答题要点

  • 第一判据不是吞吐，是「消息要保留多久」和「会不会有第二类消费方」
  • 只有执行层一个消费方、消息执行完即失效：Streams 够用，且大概率你已经有 Redis，零新增运维
  • 需要长期保留与任意时间点回放、或多条下游链路共用同一份数据：选 Kafka
  • 结构差异：Streams 内存为主、保留靠自己裁剪、组内分配随机；Kafka 磁盘顺序写、按 key 分区且分区内有序、消费者数受分区限制
  • Redis 持久化有损（AOF 每秒刷盘、异步复制），所以真相之源必须是数据库，流只当触发器，靠补投任务兜底
  • 一句话判断：Streams 适合触发执行，Kafka 适合数据管道

  Key points

  • The first criterion is not throughput but retention length and whether a second class of consumer will exist
  • One consumer class and messages that expire on execution: Streams is enough, and you probably already run Redis
  • Long retention with arbitrary replay, or one dataset feeding several downstream pipelines: pick Kafka
  • Structural differences: Streams is memory-first with self-managed trimming and random in-group dispatch; Kafka is sequential-disk, key-partitioned with in-partition ordering, and caps consumers at partition count
  • Redis persistence is lossy (per-second AOF fsync, async replication), so the database must be the source of truth with the stream as a trigger plus a republish sweeper
  • One-line rule: Streams triggers work, Kafka moves data
• 一条消息反复处理失败怎么办？请设计一个毒消息隔离机制。What do you do with a message that keeps failing? Design a poison-message isolation mechanism.

  国内高频海外高频进阶#message-bus#error-handling#reliability

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

  1. 这题在考你有没有踩过「一条坏消息拖垮整条流」。判断标准很简单：你的回答里有没有出现一个具体的阈值和一个具体的落地位置，没有就是在讲概念。
  2. 先把故障模式说清楚：按 at-least-once 的规矩，失败就不 ack、留在 pending 等重投，于是一条无论谁来都会失败的消息进入死循环——投递、失败、闲置超时、被接手、再失败。它自己永远好不了，还持续占用消费者的处理能力。
  3. 然后给机制，三个动作缺一不可：一、判定依据用 pending 清单自己记的投递次数，不要另建计数表；二、超过阈值（本课固定 3 次）就把消息搬到一条死信流，字段里带上原始消息 id、投递次数和失败原因；三、对原流 XACK，同时把这次执行标成失败并写入错误原因。只搬不 ack，它还躺在 pending 里等着被接手；只 ack 不搬，消息和失败原因一起消失，用户永远停在「正在思考」。
  4. 阈值的取值要给出权衡：定 1 会让一次网络抖动就把本来能成功的消息判死；定 10 会在一条必死的消息上浪费十次执行的钱和时间。3 次配合每次之间的空闲阈值，足够熬过绝大多数瞬时故障。
  5. 还要主动说出一个缺口：Redis Streams 没有原生的指数退避，重投时机由空闲阈值决定。想要退避就得自己把消息重新投递并带上「下次可执行时间」，那已经是在实现延迟队列了——这一条能体现你知道 Streams 的边界在哪。
  6. 可以预期的追问：死信流建完就完了吗？答：不。死信条数必须接进告警，它从 0 变成非 0 通常意味着有一类输入你的代码处理不了，是真 bug 而不是运气差；还要留一个重放入口——把死信里的字段原样投回原流即可，因为幂等键还在，重放不会产生重复执行。见过团队把死信建起来半年没打开过，那等于把故障静音了。

  How to reason about it · think before answering

  1. This question probes whether you have ever watched one bad message stall an entire stream. The test is simple: does your answer contain a concrete threshold and a concrete place where isolation happens? If not, you are talking theory.
  2. Describe the failure mode first: under at-least-once you do not ack on failure, so the message stays pending and gets redelivered. A message that fails for everyone therefore loops forever — delivered, failed, idle timeout, claimed, failed — never recovering while continuously consuming worker capacity.
  3. Then give the mechanism, three actions and all of them required. One, use the delivery count the pending list already tracks rather than building a counter table. Two, past the threshold (three deliveries in this course) move the message to a dead-letter stream carrying the original id, delivery count and failure reason. Three, XACK the original stream and mark the run failed with the error recorded. Moving without acking leaves it pending for another takeover; acking without moving makes both the message and its reason disappear, leaving the user stuck on 'thinking'.
  4. Justify the threshold: one delivery kills messages that a single network blip would have let through; ten wastes ten executions of money and time on a message that can never succeed. Three deliveries, spaced by the idle threshold, survives almost all transient faults.
  5. Volunteer a limitation: Redis Streams has no native exponential backoff — redelivery timing is governed by the idle threshold. Backoff requires republishing the message with a next-eligible timestamp, which means building a delay queue yourself. Naming this shows you know where Streams ends.
  6. Expect: is creating the dead-letter stream the end of it? No. Its depth must be alerted on, since going from zero to non-zero usually means a class of input your code cannot handle — a real bug, not bad luck. Keep a replay path too: republish the stored fields back to the original stream, and because the idempotency key is preserved, replay cannot cause duplicate execution. Teams that build a dead-letter stream and never open it have simply muted their failures.

  答题要点

  • 故障模式：at-least-once 下失败不 ack，一条永远失败的消息会无限重投并持续占用消费者
  • 判定依据用 pending 清单里记的投递次数，不需要另建计数表
  • 阈值固定 3 次：定 1 会误杀瞬时故障，定 10 会在必死消息上浪费十次执行成本
  • 隔离动作三件缺一不可：搬到死信流（带原始 id、投递次数、失败原因）、对原流 XACK、把这次执行标成失败并写入原因
  • Redis Streams 没有原生指数退避，重投时机由空闲阈值决定，要退避得自己实现延迟投递
  • 死信流要接告警并留重放入口；幂等键还在，重放不会导致重复执行

  Key points

  • Failure mode: under at-least-once you do not ack on failure, so an always-failing message is redelivered forever and keeps consuming worker capacity
  • Use the delivery count already tracked in the pending list rather than a separate counter table
  • Fix the threshold at three deliveries: one kills transient failures, ten wastes ten executions on a message that can never succeed
  • Isolation needs all three actions: move to a dead-letter stream with original id, delivery count and reason; XACK the original stream; mark the run failed with the error stored
  • Redis Streams has no native exponential backoff — redelivery timing follows the idle threshold, so backoff means implementing delayed republishing yourself
  • Alert on dead-letter depth and keep a replay path; the idempotency key survives, so replay cannot duplicate execution

D10 分片与租约：userId 哈希→shard、SET NX + TTL + Lua 续约、同用户顺序、handoff

• 租约为什么必须配合 TTL？续约为什么要用 Lua 脚本，而不是先 GET 再 PEXPIRE？Why must a lease carry a TTL, and why renew it with a Lua script instead of GET followed by PEXPIRE?

  国内高频海外高频进阶#lease#redis#atomicity

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

  1. 这题有两个考点，第二个才是区分度。第一个考点其实是在问「你知不知道租约和分布式锁不是一回事」——先把这条说清：锁的语义是互斥（我持有、你等待，我主动 release 你才拿得到），租约的语义是带过期时间的所有权（持有者不 release 也会失效，因为它可能永远不会回来了）。
  2. 由此推出 TTL 的必要性：持有者会被 kill -9、会断网、会整台机器掉电，它没有机会归还。没有 TTL 就是一把永不释放的锁，那个 shard 从此永久荒废，只能靠人工介入。TTL 的全部意义是「不需要任何人干预，所有权会自己失效」。
  3. 顺手说出 TTL 的取舍，证明你调过：太短则一次垃圾回收停顿或网络抖动就丢租约，shard 反复易主、用户会话来回搬家；太长则真死了之后要等满一个 TTL 才有人接手。常见口径是 TTL 30 秒、续约间隔取 TTL 的三分之一（10 秒），这样能连续失败两次而不丢租约。
  4. 第二个考点是原子性。两步写法的失败时间线要具体讲出来：GET 返回「是我的」，紧接着的两毫秒里租约恰好到期被 Redis 删除、另一个 worker SET NX 抢到，然后你的 PEXPIRE 执行成功——你续的是对手的租约，而自己还以为持有。如果第二步用的是 SET 而不是 PEXPIRE，你还会把对手的名字覆盖成自己，两个进程一起动手。
  5. 结论要落到通用原理上：检查和改动必须是一个不可分割的动作（compare-and-swap）。Redis 单线程执行命令，一整段 EVAL 对其他客户端就是一个原子步骤，所以 Lua 在这里不是为了性能，是为了把 GET 和 PEXPIRE 粘成一条。等价手段还有 Redis 函数、或用 WATCH 加事务重试，但 Lua 最直接。
  6. 可预期的追问：续约返回 0 应该怎么办？答「立刻放手」——把这个 shard 从持有集合里删掉、停止取消息、手上那条没做完的不许再写。返回 0 只打一行警告日志然后继续跑，是脑裂最常见的来源。再加一条自杀规则：距上次成功续约超过 TTL 的三分之二就主动全部放手。

  How to reason about it · think before answering

  1. There are two things being tested and the second is the discriminator. The first is really 'do you know a lease is not a lock': a lock means mutual exclusion (I hold, you wait, you get it when I release), while a lease means ownership with an expiry (it lapses even if the holder never releases, because the holder may never come back).
  2. That gives you the necessity of the TTL: holders get kill -9'd, lose the network, lose the whole machine — they never get to hand anything back. Without a TTL you have a lock that is never released and a shard that is permanently orphaned until a human intervenes.
  3. Volunteer the TTL trade-off to show you have tuned this: too short and a GC pause or a network blip costs you the lease, so shards flap and sessions keep migrating; too long and a genuinely dead worker's shards sit idle for a full TTL. A common setting is a 30 second TTL renewed every 10 seconds (one third), which tolerates two consecutive renewal failures.
  4. The second point is atomicity, and you should spell out the failing interleaving: GET says the lease is yours, then within two milliseconds it expires, Redis drops it, another worker wins it with SET NX, and your PEXPIRE succeeds — you have just extended your rival's lease while believing you still hold the shard. If step two is SET rather than PEXPIRE you also overwrite their owner field and both processes start working.
  5. Land on the general principle: check-and-mutate must be indivisible (compare-and-swap). Redis executes commands single-threaded, so one EVAL is a single atomic step to every other client — Lua here is not about performance, it is about fusing GET and PEXPIRE. Redis Functions or WATCH plus a transaction retry are equivalent, but Lua is the most direct.
  6. Expect the follow-up: what should a renewal returning 0 do? Let go immediately — drop the shard from the held set, stop consuming, and refuse to write the in-flight item. Logging a warning and carrying on is the most common source of split brain. Add a self-kill rule too: if the last successful renewal is older than two thirds of the TTL, release everything.

  答题要点

  • 租约不是锁：锁是互斥，租约是带过期时间的所有权；持有者可能永远不会回来，所以所有权必须能自己失效
  • 没有 TTL 就是永不释放的锁，持有者被 kill 之后那个 shard 永久荒废
  • TTL 30 秒、续约间隔 10 秒（TTL 的三分之一），留出连续两次续约失败的余量
  • 两步续约的窗口里租约可能已易主，你的 PEXPIRE 会替对手延长任期，而自己仍以为持有
  • Lua 的作用是把「比较持有者」和「续期」粘成一个原子步骤，不是为了性能；续约返回 0 必须立刻放手

  Key points

  • A lease is not a lock: locks give mutual exclusion, leases give ownership with an expiry, because the holder may never return
  • Without a TTL you have a never-released lock and a permanently orphaned shard once the holder is killed
  • A 30 second TTL renewed every 10 seconds leaves headroom for two consecutive renewal failures
  • In the two-step window the lease may already have changed hands, so your PEXPIRE extends a rival's term while you still think you hold it
  • Lua fuses the ownership check and the extension into one atomic step; a renewal returning 0 means let go immediately
• 在一个多 worker 的 Agent 服务里，怎么保证同一个用户的消息严格按顺序被处理？In a multi-worker agent service, how do you guarantee that one user's messages are processed in strict order?

  国内高频海外高频进阶#ordering#sharding#distributed-systems

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

  1. 这题是系统设计小题，考的是你能不能把「顺序」拆成分层的保证，而不是丢一个中间件名字。只答「用 Kafka 按 key 分区」不算错，但没有回答「分区之后进程内怎么办」，会被追着问。
  2. 拆法是从消息进入系统到产生副作用，逐层点出谁在保顺序，一共四层。第一层入队有序：接入层落库时给同一会话的消息发连续 seq，并按 seq 投递，总线对同一条流是追加有序的，这层几乎免费。第二层消费者唯一：同一个分片同一时刻只有一个 worker 在读，靠租约实现——这是跨进程的那一半。
  3. 第三层进程内串行：同一个分片内不能并发处理两条消息。这一层最容易被自己破坏——为了提高吞吐把一批消息丢进 Promise.all 或线程池，顺序就在自己的代码里丢掉了。要明确说出「租约保住跨进程的顺序，await 保住进程内的顺序，缺一不可」。第四层在途优先：前任 worker 挂掉时手上可能有一条已领取但没确认的消息，接管者必须先把它 claim 回来再读新消息，否则新消息会插到旧消息前面。
  4. 紧接着说串行的代价，这是面试官判断你有没有上过线的地方：串行意味着一个用户的慢请求会挡住同一个分片上其他用户的消息，一次 20 秒的模型调用能让这个 worker 名下的几十个分片全部停摆。正确做法是按分片并行、分片内串行——每个持有的分片各起一条独立处理链。并行的单位是分片，不是消息。
  5. 主动划边界：这套机制只保证同一个用户的顺序，不保证跨用户的全局顺序。全局有序需要把并行度压到 1，那就没有分布式可谈了。顺序性和并行度是一对反比，分片的意义就是把「必须有序」的范围缩到刚好够用的最小值。
  6. 可预期的追问一：不用租约行不行？可以，Kafka 按 key 分区、或者让 Gateway 直连固定 worker（粘性路由）都能得到亲和性，但代价分别是分区数难改、以及 worker 挂掉时需要额外的故障转移机制——租约恰好把故障转移也一并解决了。追问二：能不能干脆让业务对乱序免疫？部分可以，比如把「追加消息」设计成幂等且可交换的写入，但只要存在不可逆的副作用（退款、发货），顺序就必须保。

  How to reason about it · think before answering

  1. This is a small system-design question testing whether you can decompose ordering into layered guarantees rather than naming a middleware. 'Partition by key in Kafka' is not wrong, but it leaves 'and inside the process?' unanswered, which is exactly where they will push.
  2. Decompose it along the path from ingress to side effect, four layers. One, ordered ingress: the gateway assigns consecutive seq numbers per session on write and publishes in seq order; a single stream is append-ordered, so this layer is nearly free. Two, single consumer: only one worker reads a given shard at a time, enforced by the lease — that is the cross-process half.
  3. Three, in-process serialization: no two messages from the same shard may be handled concurrently. This is the layer people break themselves, by dropping a batch into Promise.all or a thread pool to raise throughput. Say it explicitly: the lease preserves order across processes, await preserves it inside one. Four, in-flight first: a killed predecessor may hold a delivered but unacknowledged message, so the successor must claim it back before reading anything new, otherwise a newer message jumps ahead of an older one.
  4. Then name the cost of serialization, which is where they judge whether you have shipped this: a single slow request blocks other users on the same shard, and one 20-second model call can stall every shard that worker owns. The right shape is parallel across shards, serial within a shard — one independent processing chain per held shard. The unit of parallelism is the shard, not the message.
  5. Volunteer the boundary: this only guarantees per-user order, never a global order across users. Global ordering requires parallelism of one, which defeats the point. Ordering and parallelism trade off directly, so sharding exists to shrink the 'must be ordered' scope to the smallest useful unit.
  6. Expect two follow-ups. Could you skip leases? Yes — Kafka key partitioning or sticky routing from the gateway to a fixed worker also gives affinity, at the cost of rigid partition counts or of needing a separate failover mechanism when a worker dies; the lease happens to solve failover at the same time. Could the business simply tolerate reordering? Partly, if appends are idempotent and commutative, but any irreversible side effect such as a refund or a shipment forces you to preserve order.

  答题要点

  • 把顺序拆成四层：入队有序（连续 seq）、消费者唯一（租约）、进程内串行（逐条 await）、在途消息优先被接管者 claim 回来
  • 租约保住跨进程的顺序，await 保住进程内的顺序，缺一不可——用 Promise.all 提吞吐会当场毁掉顺序
  • 并行的单位是分片不是消息：每个持有的分片各起一条独立处理链，否则一次慢调用会拖停这个 worker 的全部分片
  • 只保证同一用户的顺序，不保证跨用户全局有序；顺序性和并行度是反比，分片就是把有序范围缩到最小
  • 替代方案是 Kafka 按 key 分区或粘性路由，但它们不自带故障转移；只要存在不可逆副作用，顺序就必须保

  Key points

  • Decompose ordering into four layers: ordered ingress with consecutive seq, a single consumer per shard via the lease, in-process serialization with await, and claiming the predecessor's in-flight message first
  • The lease preserves order across processes and await preserves it within one — reaching for Promise.all to raise throughput destroys it
  • The unit of parallelism is the shard, not the message: one chain per held shard, or a single slow call stalls every shard that worker owns
  • Only per-user order is guaranteed, never a global order; ordering trades off against parallelism, so sharding shrinks the ordered scope
  • Alternatives are Kafka key partitioning or sticky routing, but neither brings failover; any irreversible side effect makes ordering mandatory

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

• 多个客户端同时订阅同一次执行的流式输出，怎么保证每个客户端都收到完整且有序的内容？Several clients subscribe to the same run's streaming output at once. How do you guarantee each of them receives the full content in order?

  国内高频海外高频进阶#sse#ordering#fan-out

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

  1. 题眼有两个词：完整、有序。很多人只答有序，漏掉完整——而「完整」那一半恰好是最容易设计错的，因为它取决于你用了哪种读法。
  2. 先给一句能定调的判断：一次执行是执行的单位，一条连接是观看的单位，两者不是一对一。手机和电脑同开、两个标签页、重连瞬间新旧连接并存，都会让同一次执行上挂着多条流。想清楚这句话，「谁先连谁独占」这种锁的方案就自然被排除了。
  3. 接着点出「完整」的真正机关：广播读法与消费组是两种语义。消费组是分摊，一条消息只给一个消费者；这里要的是广播，每个订阅者都要看到全部。用消费组做扇出，结果就是两条连接各拿到半段话——这是这道题最常见的错误答案。
  4. 再答「有序」：每个片段带一个从 0 开始、连续、不跳号的序号，写进流；接收侧维护「下一个该交付的号」，小于它的丢弃，大于它的先入缓冲，连号了再批量推出去。序号同时写进 SSE 的 id 字段，客户端不用另记一套账。
  5. 然后是必须主动说的工程代价：缓冲要有上限。如果 5 号迟迟不到，6 号往后全在内存里排队，一万条连接同时这样就是一次内存事故。做法是给缓冲设条数上限和等待上限，超时就从库里补读，补不到就发 error 让客户端重连——能等，但不能无限等。
  6. 可以预期的追问：扇出实现怎么选？两种——每条连接各自去读一遍流（简单，代价是同一批数据被读 N 次），或进程内只读一次再广播给本地订阅者（省读取，但要维护订阅者表、要处理最后一个订阅者离开，跨实例仍要各读一次）。判据是每次执行的平均订阅者数，多数产品接近 1，那就选前者，别为不存在的规模提前写一层。

  How to reason about it · think before answering

  1. Two words carry the question: complete and ordered. Most candidates answer only ordering and drop completeness — which is the half that is easy to get structurally wrong, because it depends on which read primitive you pick.
  2. Set the frame first: a run is the unit of execution, a connection is the unit of viewing, and they are not one-to-one. Phone plus laptop, two browser tabs, or the overlap window during a reconnect all put multiple streams on one run. Once that is clear, 'first connection wins the lock' schemes fall away on their own.
  3. Name the trap in 'complete': broadcast reads and consumer groups are different semantics. A consumer group divides work — each message goes to exactly one consumer — while here every subscriber must see everything. Using a consumer group for fan-out gives you two connections each holding half the answer, and that is the classic wrong answer here.
  4. Then ordering: every chunk carries a sequence number starting at 0, contiguous, never skipping, and is written to the stream. The reader keeps a 'next to deliver' cursor, discards anything below it, buffers anything above it, and flushes contiguous runs. Put the same number in the SSE id field so the client keeps no separate bookkeeping.
  5. Volunteer the cost: the reorder buffer needs bounds. If chunk 5 is late, 6 onward pile up in memory, and ten thousand connections doing that is an outage. Cap the buffer size and the wait, then backfill the gap from the database, and if that fails emit an error event and let the client reconnect. Wait, but never wait forever.
  6. Expect the fan-out follow-up: either every connection reads the stream itself (simple, at the cost of reading the same data N times) or one read per process broadcast to local subscribers (fewer reads, but you now own a subscriber registry, teardown when the last one leaves, and still one read per instance). Decide by average subscribers per run — usually close to one, so take the simple path.

  答题要点

  • 一次执行是执行单位、一条连接是观看单位，两者不是一对一，不需要「谁先连谁独占」的锁
  • 输出流必须用广播读法而不是消费组：消费组是分摊，会让两条连接各拿到半段话
  • 每个片段带从 0 开始、连续、不跳号的序号，接收侧按序交付：小于当前号丢弃、大于当前号入缓冲、连号批量推
  • 序号同时写进 SSE 的 id 字段，客户端不必自己记账，也是重连续号的依据
  • 缓冲必须有条数与时间上限，超时从库里补读，补不到就发 error 让客户端重连

  Key points

  • A run is the unit of execution and a connection is the unit of viewing; they are not one-to-one, so no first-wins lock is needed
  • Read the output stream as a broadcast, not through a consumer group — a group divides messages and leaves each connection with half the answer
  • Tag every chunk with a contiguous sequence starting at 0; the reader discards older, buffers newer, and flushes contiguous ranges
  • Mirror that sequence into the SSE id field so clients need no extra bookkeeping and can resume from it
  • Bound the reorder buffer by size and time, backfill gaps from the database, and fall back to an error event plus reconnect
• 用户在 Agent 还没回复完的时候又发来一条消息，应该怎么处理？A user sends another message while the agent is still answering the previous one. How should the system handle it?

  国内高频海外高频进阶#interrupt-merge#state-machine#cost

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

  1. 这题看起来是产品题，其实考的是你有没有想过「并发两次执行」的后果。答「排队处理」或「直接取消上一条」都不算错，但都不完整——面试官想听的是判据和代价。
  2. 先说清不处理会怎样：两次执行同时往同一个会话里写输出，前端看到两段交错的文字；而且第一次执行是基于不完整的信息跑的，它的答案注定要被推翻。这两条后果一说，方案的方向就定了——要合并，不要并发。
  3. 然后给可执行的判据，三个条件全中才合并：同一个会话、上一次执行正处于 running 或 streaming、距它创建不到 30 秒。命中就把新消息追加进同一次执行的输入并标记为需要重跑，不新建；超窗或上一次已完成就正常新建。把 pending 排除掉是有意的——那段窗口只有几毫秒，排除后判据不必考虑「执行侧正好在这一刻读输入」的竞态。
  4. 两个实现细节最能体现动手过：一是「需要重跑」这个标记不要写进业务表，它只在本次执行期间有意义，写进表里进程崩在半路就留下脏标记、重启后无限重跑，放一个带过期时间的键上更合适；二是重跑时序号必须接着往上加、不能重置，否则重连的客户端按上次收到的号续，会续到一段已经作废的历史上。
  5. 主动算一笔账，把「为了省钱」这个错误理由挡回去：按输入 2000、输出 500 个 token 估，单次约 0.0006 美元；不合并是两次跑完约 0.0012 美元，合并是第一遍被掐在三分之一处约 0.0004 美元加第二遍 0.0006 美元约 0.0010 美元，只省 17%，一天一万次改口也就两美元。所以合并的理由是体验，不是成本。
  6. 可以预期的追问：30 秒怎么定的？答它是产品判断不是推导结果——用户改口通常在 5 到 15 秒之间，窗口太短合并不到、太长会把新问题误并成补充；关键是这个数只在一处定义、被判据与前端提示共同引用，不要在代码里散落三份。

  How to reason about it · think before answering

  1. It reads like a product question but tests whether you have thought through two concurrent runs. 'Queue it' or 'cancel the previous one' are not wrong, just incomplete — they want the criteria and the costs.
  2. Start with what happens if you ignore it: two runs write into the same conversation, so the UI shows two interleaved answers, and the first run was computed from incomplete input, so its answer is already wrong. Those two consequences point straight at merging rather than concurrency.
  3. Then give the actual test — all three must hold: same session, the previous run is running or streaming, and it was created less than 30 seconds ago. On a hit, append the new message to that run's input and flag it for a rerun instead of creating a new run; outside the window, or if the previous run finished, create a new one. Excluding pending is deliberate: that window lasts milliseconds, and excluding it keeps the rule free of races with the worker reading the input.
  4. Two implementation details show hands-on experience. First, the rerun flag does not belong in the business table — it is meaningful only during this execution, and persisting it means a crash mid-flight leaves a dirty flag that makes the run loop forever after restart; an expiring key is the right home. Second, on rerun the sequence must keep counting up rather than resetting, or a reconnecting client resuming from its last id lands in a history that has been invalidated.
  5. Volunteer the arithmetic to kill the 'saves money' answer: at roughly 2000 input and 500 output tokens, one answer costs about $0.0006. Not merging means two full runs, about $0.0012; merging means a first pass cut off a third of the way in (about $0.0004) plus a full second pass ($0.0006), about $0.0010 — a 17% saving, which is two dollars a day even at ten thousand corrections. Merging is a user-experience decision, not a cost optimization.
  6. Expect: where does 30 seconds come from? It is a product judgment, not a derivation — corrections usually arrive 5 to 15 seconds in, too short misses them and too long merges genuinely new questions into old ones. What matters is defining it once and referencing it from both the rule and the UI hint rather than scattering the constant.

  答题要点

  • 不合并的两个后果：两段输出交错写进同一个会话，且第一次执行基于不完整信息注定被推翻
  • 判据三条全中才合并：同一会话、上一次执行处于 running 或 streaming、距创建不到 30 秒；否则正常新建
  • 命中就把新消息追加进同一次执行的输入并标记需要重跑，标记放带过期时间的键上而不是业务表
  • 重跑时序号继续往上加、绝不重置，否则断线重连会续到作废的历史上
  • 合并省的钱有限（约 17%），真正的理由是不让两个回答同时对着用户说话

  Key points

  • Without merging you get two interleaved answers in one conversation, and the first was computed from incomplete input
  • Merge only when all three hold: same session, previous run running or streaming, created under 30 seconds ago; otherwise create a new run
  • On a merge, append to the same run's input and flag a rerun, keeping that flag in an expiring key rather than the business table
  • Sequence numbers keep counting on rerun and are never reset, or reconnects resume into an invalidated history
  • The cost saving is small (about 17%); the real reason is to avoid two answers talking over each other

D12 长期记忆：pgvector、embedding、chunking、memory_search 工具

• pgvector 和专用向量数据库相比，优劣分别是什么？你会怎么选？How does pgvector compare with a dedicated vector database, and how would you choose?

  国内高频海外高频进阶#vector-database#pgvector#architecture

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

  1. 这题考的是选型判断力，不是产品参数背诵。开口就报「Milvus 支持分布式、Qdrant 过滤更强」是最没有区分度的答法——面试官想知道你按什么判据选，以及你有没有算过运维成本。
  2. 先给三个提问维度，把选型变成可推导的：数据量到什么量级、要不要和业务表在同一个事务里提交、过滤条件复不复杂。这三问能覆盖绝大多数真实场景。
  3. pgvector 的赢面几乎全在后两问上：记忆表和业务表在同一个库，写记忆和更新执行记录可以放进同一个事务；按用户过滤就是普通 where 条件；备份、监控、连接池、迁移工具全部复用。**多一个有状态服务的运维成本，通常比向量检索的性能更早成为瓶颈**——这句话最能体现你上过线。
  4. 再诚实地说它的天花板：单表到千万级向量时 HNSW 索引构建吃内存、写入放大明显，ANN 与元数据过滤的融合不如专用库，水平扩展只能靠 Postgres 自己那一套。不肯说缺点的人会被认为在推销。
  5. 结论要能写死：百万级以内、需要和业务表一起过滤或同事务提交、团队人手紧，用 pgvector；上千万条、检索本身就是主要负载、有专人维护，上专用库。别在第一天就选专用库。
  6. 可以预期的追问：以后想换库，迁移成本大不大？答案会让很多人意外——换库不用重算 embedding，向量是模型产出的，跟存它的库无关，导出导入即可，成本主要在双写和灰度。真正要全量重算的是换 embedding 模型，那才是硬锁定。

  How to reason about it · think before answering

  1. This is a judgment question, not a feature-recital. Opening with 'Milvus does sharding, Qdrant filters better' carries no signal — they want your decision criteria and whether you have priced the operational overhead.
  2. Offer three questions that make the choice derivable: what scale, does it need to commit in the same transaction as business tables, and how complex is the metadata filtering.
  3. pgvector wins on the last two: memories live in the same database as the business tables, so writing a memory and updating a run share one transaction; filtering by user is an ordinary WHERE clause; backups, monitoring, pooling and migrations are all reused. The line that shows operational experience is that one more stateful service usually becomes the bottleneck before vector search performance does.
  4. Be honest about the ceiling: past roughly ten million vectors in one table, HNSW index builds eat memory and write amplification shows; ANN plus metadata filtering is weaker than a purpose-built engine; horizontal scaling is whatever Postgres gives you. Refusing to name downsides reads as salesmanship.
  5. Commit to a rule: under a million vectors, needing joins or shared transactions, small team — pgvector. Tens of millions, retrieval as the primary workload, someone owning the service — dedicated store. Do not start with the dedicated store on day one.
  6. Expect the follow-up on migration cost. Switching stores does not require re-embedding — vectors belong to the model, not the store, so export and import; the cost is dual-write and rollout. Switching the embedding model is what forces a full recompute, and that is the real lock-in.

  答题要点

  • 三个判据：数据量级、要不要和业务表同事务提交、元数据过滤复不复杂
  • pgvector 的优势是同库同事务、普通 SQL 过滤、运维零新增——少一个有状态服务往往比性能更值钱
  • pgvector 的天花板：千万级向量时索引构建吃内存、写入放大、ANN 与过滤融合弱、扩展受限于 Postgres
  • 专用向量库给的是分布式分片、更强的过滤与 ANN 融合、混合检索，代价是多一个要备份要监控的有状态服务
  • 换向量库不用重算 embedding；换 embedding 模型才要全量重算，真正的锁定点是模型不是库

  Key points

  • Three criteria: scale, need for same-transaction commits with business tables, and filtering complexity
  • pgvector gives one database, one transaction, ordinary SQL filters and zero new operations — often worth more than raw performance
  • Its ceiling: memory-hungry index builds and write amplification at tens of millions, weaker ANN-plus-filter fusion, scaling limited to Postgres
  • Dedicated stores buy sharding, better filtered ANN and hybrid search, at the price of another stateful service to back up and monitor
  • Changing stores needs no re-embedding; changing the embedding model does — the lock-in is the model, not the database
• chunking 的切分策略会怎么影响检索效果？切多大合适？How does the chunking strategy affect retrieval quality, and how do you pick a chunk size?

  国内高频海外高频进阶#chunking#rag#retrieval-quality

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

  1. 题眼在「怎么影响」。只回答一个数字（比如「切 500 字」）会被追着问为什么，所以要先把两个方向的失效模式讲出来，数字才有落点。
  2. 切太碎的失效模式：单张卡片脱离上下文。「他说要 42 码」检索命中了也没用，代词失去指代，模型拿到一句悬空的话反而更容易编。
  3. 切太整的失效模式更反直觉，也是这题真正的区分点：一块横跨三个主题时，它的向量是这几个主题的平均值，结果对哪个 query 都不太像，命中率反而下降。**块越大信息越全，却越难被检索到**——能说出这句话基本就过了。
  4. 然后给可操作的口径：目标 400 字符、相邻块重叠 80 字符，并优先在句号、换行这类自然边界收尾。重叠的作用要说清楚——一句关键的话被切口劈开时，两块各拿半句，重叠保证它至少在其中一块里是完整的。
  5. 补上代价，这是工程视角：重叠 80 除以 400 等于 20% 的存储放大，向量也跟着多一份；内容高度重叠的两块可能一起被检索出来，白占返回名额，所以要按内容去重。
  6. 可以预期的追问：怎么验证切分策略好不好？答案是准备一批 query 与标注好的期望命中，量召回率和 top-k 命中率，改切分参数后重跑对比——切分是可以被度量的，不该靠感觉调。第二个追问是「对话数据要不要原样切」，答不要：先让模型抽成陈述句再切，否则大量寒暄句会把向量拉平。

  How to reason about it · think before answering

  1. The hinge is 'how does it affect'. Naming a number alone invites a why, so describe both failure modes first and let the number follow.
  2. Too small: a chunk loses its context. 'He wants size 42' retrieves fine but resolves to nothing — pronouns dangle and the model is more likely to fabricate.
  3. Too large is the counter-intuitive half and the real discriminator: a chunk spanning three topics gets a vector that averages them, so it looks only vaguely like any query and recall drops. Bigger chunks carry more information yet are harder to retrieve.
  4. Give an operational default: target 400 characters with 80 characters of overlap, ending on natural boundaries such as sentence stops or newlines. Explain the overlap — when a key sentence lands on a cut, each side holds half of it, and the overlap guarantees at least one chunk holds it whole.
  5. Add the costs: 80 over 400 is 20% storage amplification plus an extra vector per duplicated span, and near-duplicate chunks can both surface and waste result slots, so deduplicate by content before returning.
  6. Expect: how do you validate a chunking strategy? Build a query set with labelled expected hits and measure recall and top-k hit rate, then re-run after changing parameters — chunking is measurable, not a matter of taste. Second follow-up: should raw dialogue be chunked as-is? No — have the model distil it into standalone statements first, or filler turns flatten the vectors.

  答题要点

  • 切太碎：单块脱离上下文，代词失去指代，命中了也用不上
  • 切太整：一块横跨多个主题，向量被平均，对任何 query 都不够像，命中率反而下降
  • 可操作口径：目标 400 字符、重叠 80 字符，优先在句号或换行这类自然边界收尾
  • 重叠的作用是保证被切口劈开的句子至少在一块里完整；代价是约 20% 的存储放大和可能的重复命中
  • 别直接切对话原文，先抽成陈述句；切分效果要用标注好的 query 集测召回率，而不是凭感觉

  Key points

  • Too small: chunks lose context, pronouns dangle, and a hit is useless
  • Too large: one chunk spans several topics, its vector averages them, and recall drops for every query
  • Working default: target 400 characters with 80 characters of overlap, cutting on sentence or newline boundaries
  • Overlap keeps a split sentence whole in at least one chunk, at roughly 20% storage amplification plus possible duplicate hits
  • Distil dialogue into standalone statements before chunking, and validate with a labelled query set measuring recall

D13 cron 调度（中心调度→stream 投递）+ 成本计量（token→USD 台账、usage report）

• 让你从零设计一套 token 成本计量和台账系统，你会怎么做？How would you design a token cost metering and ledger system from scratch?

  国内高频海外高频进阶#cost#observability#data-modeling

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

  1. 这题在考「你有没有真的对过账」。区分度在两个地方：金额用什么类型存，以及金额是冗余存还是查询时现算。答不到这两点的方案，上线三个月就会被财务打回来。
  2. 先立判据：台账不是日志。日志是给排查问题用的，删了就删了；台账要拿去对账、要回答「这个月为什么涨了 40%」，所以每一笔钱都必须能追回到「谁、因为哪一次执行、用哪个模型、花了多少 token」。字段设计全部由这条判据推出来。
  3. 然后给字段和理由，一一对应：user_id 回答该算谁头上、run_id 回答属于哪次执行（允许为空，因为有系统级批量开销）、model 存调用当时那一个（fallback 会让同一段业务落到不同模型上）、kind 区分 chat 和 embedding（两者量级和增长曲线完全不同）、prompt_tokens 与 completion_tokens 分开存（输入输出单价差三到四倍，只存 total 就算不回金额，也看不出是提示词太长还是模型太啰嗦）。
  4. 接着是两个最能体现经验的判断。第一，金额用定点类型：数据库用 numeric，代码里用 Decimal 或 BigDecimal，绝不用双精度浮点累加，否则十万条之后总额和逐条相加对不上。第二，cost_usd 要在写入那一刻算好并冗余存，不要查询时用当前价格表现算——价格会变，历史账单不能跟着一起变，这是台账和报表最本质的区别。
  5. 还要主动说记账的时机和事务边界：记账放在「拿到 usage 字段」那一刻，而不是「业务成功」那一刻，因为失败的调用同样产生费用，尤其 fallback 会一次业务跨两三次收费调用。台账写入不必和业务同事务（丢一条只是几厘钱，锁住台账表却会卡住用户对话），可以异步加重试，用 run_id 加调用序号做唯一约束防重；但如果产品有额度限制，配额扣减必须同事务，否则用户能靠并发把额度刷穿。
  6. 可以预期的追问：厂商调价了历史数据怎么办？答案是价格表本身要有生效时间和版本号，台账里既存算好的金额也可以存价格版本，这样重算和审计都有依据。

  How to reason about it · think before answering

  1. This question tests whether you have ever reconciled a bill. The discriminators are the numeric type you store money in, and whether cost is stored or computed at query time. A design missing either gets rejected by finance within a quarter.
  2. Set the criterion first: a ledger is not a log. Logs exist for debugging and can be dropped; a ledger has to reconcile against the vendor invoice and answer why the bill grew 40% this month, so every charge must trace back to who, which run, which model, and how many tokens. Every field falls out of that.
  3. Then walk the fields with reasons: user_id says whose budget it hits; run_id says which execution it belongs to and is nullable because some spend is system-level batch work; model records the one actually used, since fallback routes the same workload to different providers; kind separates chat from embedding because their volumes and growth curves differ completely; prompt_tokens and completion_tokens are stored separately because input and output differ three- to four-fold in price, and a single total can neither reproduce the amount nor tell you whether the prompt is bloated or the model is verbose.
  4. Now the two judgments that show experience. First, money uses fixed-point: numeric in the database, Decimal or BigDecimal in code, never accumulated in binary floats, or the total will diverge from the sum of rows after a hundred thousand entries. Second, cost is computed at write time and stored redundantly, not recomputed from the current price table — prices change, and history must not change with them. That is the essential difference between a ledger and a report.
  5. Volunteer the timing and transaction boundary: record at the moment you receive the usage field, not at business success, because failed calls still cost money and a fallback spans two or three billable calls per business operation. Ledger writes need not share the business transaction — losing a row costs fractions of a cent, while locking the ledger table stalls user conversations — so write asynchronously with retries and a uniqueness constraint on run id plus call index. The exception is quota enforcement: if the product caps spend, the decrement must be transactional or concurrent requests will blow through the cap.
  6. Expect: what happens to history when the vendor changes prices? The price table itself needs effective dates and a version, and the ledger stores both the computed amount and the price version, so recomputation and audit both have a basis.

  答题要点

  • 台账不是日志：每一笔钱要能追回到谁、哪一次 run、哪个模型、多少 token，字段设计全由这条判据推出
  • prompt_tokens 与 completion_tokens 必须分开存，因为输入输出单价差三到四倍，只存 total 既算不回金额也看不出问题出在哪一侧
  • 金额用定点类型（数据库 numeric、代码 Decimal/BigDecimal），不要用浮点累加，否则总额和逐条相加对不上
  • cost_usd 在写入那一刻算好并冗余存，不要查询时按当前价格现算——价格会变，历史账单不能跟着变
  • 记账时机是拿到 usage 字段那一刻而不是业务成功那一刻，失败调用和 fallback 同样产生费用；台账可异步写入加重试，但配额扣减必须和业务同事务

  Key points

  • A ledger is not a log: every charge must trace to a user, a run, a model and a token count, and the schema follows from that
  • Store prompt and completion tokens separately, since input and output prices differ three- to four-fold and a single total can neither reproduce the amount nor localize the problem
  • Use fixed-point money (numeric in the database, Decimal or BigDecimal in code); float accumulation makes totals disagree with the sum of rows
  • Compute cost at write time and store it, rather than recomputing from today's price table, so history stays stable when prices change
  • Record at the moment usage is returned, not at business success — failed calls and fallbacks still cost money; ledger writes can be async with retries, but quota decrements must be transactional
• 一份 LLM 应用的 usage report 通常要覆盖哪些维度？这些维度分别用来做什么决策？Which dimensions should a usage report for an LLM product cover, and what decision does each one drive?

  国内高频海外高频进阶#observability#cost#reporting

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

  1. 这题最容易答成罗列维度：按用户、按天、按模型、按功能……列得越全越显得没想过。区分度在后半句——每个维度对应的是哪一类行动。列不出行动，说明你只做过报表没用过报表。
  2. 先给三个主维度和它们各自的行动类型：按用户切是商业动作（谁该涨价、谁在滥用、定价分层能不能覆盖成本）；按天切是排障动作（对齐发布时间线，找出是哪次上线让成本跳了台阶）；按模型和调用类型切是优化动作（验证分层路由有没有真省到钱、embedding 的量是不是失控了）。三个维度对应三个不同的看板受众。
  3. 然后升一层，指出绝对金额没有信息量，真正有用的是带分母的单位经济学指标：每次执行成本（当月总成本除以 run 数）、每用户月成本（除以活跃用户数）、每美元产出（完成的业务动作数除以总成本）。前两个用来判断定价能不能覆盖成本，第三个用来判断这套系统值不值得继续投入。
  4. 举一个能落地的用法证明你真用过：每次执行成本这个比值是把尺子。如果用户数没涨而单次成本涨了，几乎一定是某次上线让提示词变长了，或者某个工具的返回体膨胀了——这个信号通常比超时告警早好几天出现，所以成熟团队会把成本曲线和错误率、延迟并排挂在值班大盘上。
  5. 最后补一个大多数人会漏的维度：失败与降级。失败的调用照样收费，fallback 会让一次业务操作跨两三次收费调用。报表里不单独切出这一块，你和厂商账单的差额就会恰好集中在故障期，也就是最需要看清成本的时候。
  6. 可以预期的追问：报表要做到什么实时度？答案是分层——按天的汇总离线跑就够，但配额和预算护栏需要近实时的当月累计，通常用一张按用户按月的汇总表增量更新，而不是每次请求都扫一遍明细。

  How to reason about it · think before answering

  1. The trap is listing dimensions: by user, by day, by model, by feature. Length signals you have not thought about it. The discriminator is the second half — which action each dimension drives. No action means you built reports but never used one.
  2. Give three primary dimensions with their action type: by user is a commercial action (who to reprice, who is abusing, whether tiering covers cost); by day is a debugging action (align with the release timeline to find which deploy stepped the cost up); by model and call kind is an optimization action (did tiered routing actually save money, is embedding volume running away). Three dimensions, three different dashboard audiences.
  3. Then go up a level: absolute dollars carry no information. What matters are unit-economics ratios with a denominator — cost per run (monthly cost over run count), cost per active user per month, and business actions completed per dollar. The first two say whether pricing covers cost; the third says whether the system deserves further investment.
  4. Prove you have used it with a concrete pattern: cost per run is a ruler. If user count is flat but cost per run climbs, it is almost always a deploy that lengthened the prompt or a tool whose response body grew. That signal usually appears days before latency alerts, which is why mature teams put the cost curve next to error rate and latency on the on-call dashboard.
  5. Add the dimension most people miss: failures and fallbacks. Failed calls are still billed, and a fallback spans two or three billable calls per business operation. Without slicing that out, your gap against the vendor invoice concentrates exactly during incidents, when you most need cost clarity.
  6. Expect: how fresh does the report need to be? Tier it — daily rollups can run offline, but quota and budget guardrails need near-real-time month-to-date totals, usually from an incrementally updated per-user monthly summary table rather than scanning the detail rows on every request.

  答题要点

  • 按用户切是商业动作（定价分层、异常账号），按天切是排障动作（对齐发布找成本跳变），按模型和调用类型切是优化动作（验证分层路由、盯 embedding 用量）
  • 绝对金额没有信息量，要看带分母的指标：每次执行成本、每用户月成本、每美元产出
  • 每次执行成本是把尺子：用户数没涨而单次成本涨了，通常是提示词变长或工具返回体膨胀，比超时告警早好几天出现
  • 必须单独切出失败与降级的开销，否则和厂商账单的差额会集中在故障期
  • 实时度要分层：按天汇总可离线跑，预算护栏需要近实时的当月累计，用增量汇总表而不是每次扫明细

  Key points

  • By user drives commercial decisions, by day drives debugging, and by model or call kind drives optimization — three dimensions, three audiences
  • Absolute dollars say nothing; use ratios with a denominator: cost per run, cost per active user per month, and business actions per dollar
  • Cost per run is a ruler: flat users with rising per-run cost usually means a longer prompt or a bloated tool response, and it shows days before latency alerts
  • Slice out failed and fallback calls, or your gap against the vendor invoice concentrates during incidents
  • Tier the freshness: daily rollups offline, near-real-time month-to-date totals from an incremental summary table for budget guardrails

D14 部署运维：compose 多 worker、心跳、健康检查、优雅停机、dev/prod 隔离；W2 复盘

• 多实例部署下，怎么设计心跳和健康检查？两者是同一件事吗？With multiple replicas, how do you design heartbeats and health checks? Are they the same thing?

  国内高频海外高频进阶#observability#deployment#distributed-systems

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

  1. 题眼是「两者是同一件事吗」。答「都是探活」直接失分——面试官想看你能不能把一个词拆成三个不同的问题，因为混起来会造成真事故。
  2. 先拆问题：存活探针回答「这进程要不要被重启」，就绪探针回答「现在能不能给我发流量」，心跳面板回答「集群此刻是什么状态」。三者的读者不同：前两个给编排系统，第三个给人。
  3. 再说心跳为什么不可省：编排系统只能看到进程存活，而 Worker 完全可以进程活着而活儿全停——事件循环被死循环占住、连接池耗尽后取消息全超时、宿主机 CPU 被邻居打满。这类假死恰好是编排系统看不见的那种，只有业务自己上报的心跳能发现。
  4. 方向也要答对：心跳是副本自己 push，不是 Gateway 逐个 pull。因为容器随时换 IP 和主机名，去问的一方需要一份永远在变的名单，而那份名单本身就得靠心跳维护，逻辑绕回来了。上报内容至少三样：时间戳判活、在跑任务数区分闲和忙、版本号在滚动发布时看新旧两批各剩几个。
  5. 最关键的一刀是隔离性：**不要把下游依赖查进就绪探针**。一个 Worker 失联导致所有 Gateway 的就绪探针同时转红，编排系统会把整个接入层摘光——一个非核心故障被自己升级成全站不可用。而实际上那个 Worker 失联根本不影响接单：消息还在流里，没确认的会被别人接手，它的租约会因 TTL 到期而易主。
  6. 可以预期的追问：那 Gateway 怎么判断某个 Worker 可不可用？答「它不判断，也不需要判断」——Gateway 从不指定某个 Worker 干活，派活由消费组和租约决定，心跳的用途是观测和告警，不是路由。答到这里就说明你真的想清楚了分层。

  How to reason about it · think before answering

  1. The hinge is are they the same thing. Answering both check liveness loses the point — the interviewer wants to see you split one word into three distinct questions, because conflating them causes real outages.
  2. Separate them: a liveness probe answers should this process be restarted, a readiness probe answers can you send me traffic now, and a heartbeat dashboard answers what is the cluster's state. The audiences differ: the first two are for the orchestrator, the third is for a human.
  3. Then say why heartbeats are not optional: the orchestrator only sees process liveness, but a worker can be alive while doing no work at all — a blocked event loop, an exhausted connection pool timing out every read, a noisy neighbour saturating host CPU. This kind of zombie is exactly what the orchestrator cannot see, and only an application-level heartbeat catches it.
  4. Get the direction right too: replicas push their own heartbeat rather than the gateway polling each one. Containers change IP and hostname constantly, so a poller needs a roster that is always changing — and maintaining that roster is what heartbeats are for, so the logic is circular. Report at least three things: a timestamp for liveness, in-flight count to distinguish idle from overloaded, and a version so you can watch old and new replicas during a rollout.
  5. The sharpest point is isolation: do not query downstream dependencies inside a readiness probe. One worker going quiet would turn every gateway's readiness red, and the orchestrator would pull the entire ingress layer — turning a non-critical fault into a full outage. In reality that worker's absence does not stop intake at all: messages sit in the stream, unacked ones get claimed by someone else, and its lease changes hands when the TTL expires.
  6. Expect: so how does the gateway decide whether a worker is usable? Answer that it does not, and does not need to — the gateway never assigns work to a specific worker; the consumer group and the lease decide that. Heartbeat data is for observability and alerting, not routing. Getting here shows you actually understand the layering.

  答题要点

  • 一个词要拆成三个问题：存活探针（要不要重启）、就绪探针（能不能发流量）、心跳面板（集群什么状态），前两个给编排系统、第三个给人
  • 编排系统只看得见进程存活，看不见假死（事件循环卡住、连接池耗尽、CPU 被抢），所以业务层心跳不可省
  • 心跳必须是副本 push 而不是 Gateway pull：容器随时换 IP，pull 需要一份靠心跳才能维护的名单，逻辑绕回来了
  • 上报时间戳、在跑任务数、版本号三样，分别用于判活、区分忙闲、观察滚动发布进度
  • 不要把下游依赖查进就绪探针，否则一个 Worker 失联会让整个接入层被摘掉，把非核心故障升级成全站不可用
  • Gateway 不判断 Worker 可用性——派活由消费组和租约决定，心跳只用于观测告警，不用于路由

  Key points

  • Split one word into three questions: liveness (restart me?), readiness (send me traffic?), heartbeat dashboard (what is the cluster doing?) — first two for the orchestrator, third for humans
  • The orchestrator sees process liveness but not zombies (blocked loop, exhausted pool, stolen CPU), so an application-level heartbeat is mandatory
  • Heartbeats must be pushed by replicas, not polled by the gateway: containers change IP constantly and polling needs a roster that heartbeats themselves maintain
  • Report timestamp, in-flight count and version — for liveness, load, and rollout progress respectively
  • Never query downstream dependencies in a readiness probe, or one quiet worker pulls the whole ingress layer and escalates a minor fault into an outage
  • The gateway does not judge worker availability — the consumer group and lease assign work; heartbeats are for observability, not routing
• 什么是优雅停机？为什么直接 kill 进程有风险？请说出具体步骤。What is graceful shutdown, and why is killing a process outright risky? Walk through the steps.

  国内高频海外高频进阶#deployment#reliability#operations

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

  1. 这题考的是「你有没有真的发过版」。答「等任务跑完再退出」只是定义，面试官要的是代价、步骤和顺序。
  2. 先把代价说具体。发版、缩容、机器维护、抢占式实例回收都会先发 SIGTERM、等宽限期、超时 SIGKILL。SIGKILL 拦不住，落到正在跑 Agent 循环的 Worker 身上：这次的 run 永远停在 running，用户界面一直转圈；模型调用的钱已经付了，回复却没落库；没确认的消息要等空闲阈值到了才被别人接手，用户白等一轮。一次发版掐断几十次对话，这就是日常代价。
  3. 然后给三步，强调顺序不能变：第一步拒新——把开关拨过去，消费循环下一轮不再从流里取消息（已经读到手上还没开始的那几条，留在 pending 里由别人接手，比硬扛完一整批更快）；第二步等手头这次执行跑完，但要有上限；第三步主动交还租约、从心跳面板注销，然后退出。
  4. 第二步的上限是加分点：一次卡死的模型调用会让你永远等不到，而宽限期一到照样 SIGKILL。与其被动挨刀，不如自己认输退出——没确认的消息还在 pending 里，别人会接手重做。本课取 20 秒，取法是「一次正常执行的耗时上限」再留余量。
  5. 第三步也是加分点：租约本来靠 TTL 到期自然易主，但那是为进程猝死准备的。计划内下线你明知道自己要走，主动交还能让接手方下一轮扫描就上岗，而不是白等一个 TTL。交还必须带条件——只删还写着自己名字的那把牌子，否则租约已过期、别人刚抢到时，你就把对方的值班牌撕了。
  6. 最后两件配套的事，漏一件前面全白做：宽限期的配置必须大于代码里的等待上限（代码等 20 秒而 compose 默认只等 10 秒，第 10 秒就 SIGKILL，三步只走到一半）；以及信号得真的传到你的进程（启动命令写成包管理器，PID 1 就是包管理器，SIGTERM 未必传得到，停机代码一次都不会执行）。

  How to reason about it · think before answering

  1. This question tests whether you have actually shipped a release. Reciting finish in-flight work before exiting is just the definition; the interviewer wants the cost, the steps, and the ordering.
  2. Make the cost concrete. Deploys, scale-downs, host maintenance and spot reclamation all send SIGTERM, wait a grace period, then SIGKILL. SIGKILL cannot be trapped, and landing it on a worker mid-agent-loop means: the run is stuck in running forever while the user watches a spinner; you already paid for the model call but never persisted the reply; the unacked message waits for the idle threshold before anyone claims it. One deploy cuts off dozens of conversations — that is the everyday cost.
  3. Then give three steps and stress that the order is fixed. One, stop accepting work: flip a flag so the consume loop stops reading from the stream (messages already fetched but not started stay in pending for someone else, which is faster than forcing a whole batch through). Two, wait for the in-flight execution, but with a ceiling. Three, proactively release leases, deregister from the heartbeat dashboard, and exit.
  4. The ceiling in step two earns points: a hung model call means you wait forever, and the grace period will SIGKILL you anyway. Better to concede and exit — the unacked message is still pending and someone will redo it. This course uses 20 seconds, derived from the upper bound of a normal execution plus margin.
  5. Step three also earns points: leases normally change hands via TTL expiry, but that path exists for sudden death. On a planned shutdown you know you are leaving, so releasing proactively lets the successor take over on its next scan instead of waiting out a full TTL. The release must be conditional — delete only the badge that still bears your name, or you will tear down the badge of whoever just claimed it after your lease expired.
  6. Finish with two companions; miss either and the rest is wasted. The configured grace period must exceed the wait ceiling in code (code waits 20s while compose defaults to 10s, so SIGKILL lands at second 10 and your three steps only half-run). And the signal must actually reach your process (if the entrypoint is a package manager, PID 1 is the package manager, SIGTERM may never arrive, and your shutdown code never runs once).

  答题要点

  • 直接 kill 的具体代价：run 永远停在 running、用户界面一直转圈、模型的钱已付但回复没落库、没确认的消息要等空闲阈值才被接手
  • 三步且顺序不能变：拒绝新任务 → 等手头的跑完（有上限）→ 主动交还租约并注销心跳，然后退出
  • 等待必须有上限（本课 20 秒）：卡死的模型调用会让你永远等不到，宽限期一到照样被 SIGKILL，不如自己认输，消息还在 pending 里
  • 主动交还租约让接手方下一轮就上岗，而不是白等一个 TTL；交还必须条件化，只删还写着自己名字的那把
  • 宽限期配置必须大于代码里的等待上限，否则三步只执行到一半（compose 的 stop_grace_period / K8s 的 terminationGracePeriodSeconds）
  • 信号要真传到进程：用 exec 形式直接起业务进程，别让包管理器当 PID 1

  Key points

  • Concrete cost of a hard kill: the run is stuck in running, the user stares at a spinner, the model call is paid for but the reply is unsaved, and the unacked message waits out the idle threshold
  • Three steps in a fixed order: refuse new work, wait for in-flight work with a ceiling, then release leases and deregister before exiting
  • The wait needs a ceiling (20s here): a hung model call never returns and the grace period kills you anyway, so concede — the message is still pending for someone else
  • Releasing leases proactively lets the successor start on its next scan instead of waiting a full TTL; the release must be conditional on still owning it
  • The configured grace period must exceed the in-code wait ceiling, or the three steps only half-run (stop_grace_period / terminationGracePeriodSeconds)
  • Make sure the signal reaches your process: exec the business process directly rather than letting a package manager be PID 1
• 滚动发布时，如何避免正在处理的任务被打断？During a rolling deploy, how do you keep in-flight tasks from being interrupted?

  国内高频海外高频进阶#deployment#reliability#operations

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

  1. 这题是上一题的应用题，区别在于它要求你把编排系统那一侧也讲进来——只讲进程内的三步只答了一半。
  2. 完整骨架是两侧配合：编排系统先摘流量（把就绪探针转红，让负载均衡不再把新请求打过来）、再发 SIGTERM、然后等宽限期；进程在这段时间里把手头的活做完、交还所有权、干净退出。这一句话就是答案的主干，剩下都是细节。
  3. 然后区分两类副本，这是拿分点。Gateway 有入站连接，摘流量对它有意义；Worker 没有任何入站连接，它是自己去总线取活的，所谓「摘流量」对它就是「自己不再取新消息」——也就是停机三步的第一步。**同一个词在两类副本上是两种机制**，能说清这一点说明你理解拉与推的差别。
  4. 接着讲批次与顺序：一次只换一部分副本（compose 里手动分批，K8s 里靠 maxUnavailable / maxSurge），保证任何时刻都有足够的存活副本接得住流量。心跳面板上的版本号字段这时派上用场——你能看到新旧两批各剩几个，而不是盲发。
  5. 还要提一句状态兼容：滚动发布期间新旧代码同时在线，所以数据库迁移必须向后兼容（先加可空列、再双写、最后才删旧列），消息格式也不能一次性改。这是很多人漏掉的一层——进程停得再优雅，新旧版本读不了同一份数据照样出事故。
  6. 可以预期的追问：如果一次执行本来就要跑 5 分钟，宽限期不可能等那么久怎么办？答案不是把宽限期拉到 5 分钟，而是让任务可中断可重入——把长任务切成可保存进度的小步（D11 的 run 状态机和 D9 的 at-least-once 加幂等正好提供了这个基础），被打断的那一步由下一个副本接着做。

  How to reason about it · think before answering

  1. This is the applied version of the previous question, and the difference is that it demands the orchestrator's side too — describing only the in-process steps answers half of it.
  2. The full skeleton is both sides cooperating: the orchestrator first removes traffic (turns readiness red so the load balancer stops sending new requests), then sends SIGTERM, then waits out the grace period; the process uses that window to finish in-flight work, hand back ownership, and exit cleanly. That sentence is the trunk; everything else is detail.
  3. Then distinguish the two kinds of replica, which is where the points are. A gateway has inbound connections, so draining traffic means something for it. A worker has no inbound connections at all — it pulls work from the bus, so draining for it means stop fetching new messages, which is step one of graceful shutdown. The same word is two different mechanisms on the two replica types, and saying so shows you understand pull versus push.
  4. Next, batching and ordering: replace only a subset at a time (manual batches in compose, maxUnavailable / maxSurge in Kubernetes) so enough replicas are always alive to absorb traffic. This is where the version field in the heartbeat payload pays off — you can see how many old and new replicas remain instead of deploying blind.
  5. Also mention state compatibility: during a rolling deploy old and new code run simultaneously, so schema migrations must be backward compatible (add a nullable column, dual-write, drop the old column last) and message formats cannot change in one shot. Many candidates miss this layer — however gracefully processes stop, two versions that cannot read the same data will still cause an incident.
  6. Expect: what if a single execution legitimately takes five minutes and the grace period cannot wait that long? The answer is not to stretch the grace period to five minutes but to make the task interruptible and resumable — break long work into steps that checkpoint progress (the run state machine from D11 plus at-least-once with idempotency from D9 give you exactly this), so the next replica continues the interrupted step.

  答题要点

  • 完整骨架是两侧配合：编排系统先摘流量、再发 SIGTERM、等宽限期；进程在这段时间做完手头的活、交还所有权、干净退出
  • Gateway 和 Worker 的「摘流量」是两种机制：前者靠就绪探针转红让负载均衡停止转发，后者靠自己不再从总线取新消息
  • 分批替换（maxUnavailable / maxSurge 或手动分批），保证任何时刻有足够存活副本；心跳里的版本号让你看到新旧两批各剩几个
  • 新旧代码同时在线，所以数据库迁移必须向后兼容（加可空列 → 双写 → 最后删旧列），消息格式不能一次性改
  • 长任务不该靠拉长宽限期解决，而要做成可中断可重入：切成能保存进度的小步，被打断的那步由下一个副本接着做

  Key points

  • The full skeleton is both sides: orchestrator drains traffic, sends SIGTERM, waits the grace period; the process finishes in-flight work, hands back ownership, exits cleanly
  • Draining means two different things for gateways and workers: readiness turning red versus the worker itself stopping its fetch from the bus
  • Replace in batches (maxUnavailable / maxSurge or manual) so enough replicas stay alive; the version field in heartbeats shows how many old and new remain
  • Old and new code run concurrently, so migrations must be backward compatible (nullable column, dual-write, drop last) and message formats cannot change in one step
  • Long tasks are not solved by a longer grace period but by being interruptible and resumable — checkpointed steps that the next replica can continue