面试题库

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

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

• 为什么生产级 Agent 服务通常要把 Gateway 和 Worker 拆开？什么情况下不该拆？Why do production agent services usually split a gateway from workers, and when should you not split?

  国内高频海外高频基础#architecture#scalability

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

  1. 题眼在后半句。只答「解耦、可扩展」是从架构书上抄来的，面试官想知道你有没有被某个具体现象逼着拆过——所以答案里必须出现「什么现象」和「不拆的代价」。
  2. 先给一条可复用的推导链：Agent 的一次执行是长耗时且时长不可预测的（模型响应加上多轮工具调用，几秒到几十秒），而接入层要承载全部流量、必须是毫秒级的短请求；把两种时长量级差三个数量级的工作放进同一个进程，慢的那一类必然会挤占快的那一类的资源。
  3. 把现象说具体：单进程时一台机器同时跑十几次长执行，连接与内存被占满，新来的健康检查开始超时，编排系统判定实例已死并重启它——正在跑的执行全部陪葬。这个「健康检查被自己的业务拖挂」的故事比任何抽象论证都有说服力。
  4. 然后给判据：能在 Worker 做的不放 Gateway，接入层只留鉴权、限流、落库、投递这四件耗时确定的事。拆开之后 Gateway 无状态可以任意扩缩，Worker 的并发度可以按模型配额单独调，两者的扩容曲线本来就不一样。
  5. 主动说代价，这是区分度所在：接口语义从 200 变成 202，客户端要多一次订阅往返；系统里多了一条总线和一张 runs 表，可观测性和排障链路都变长；本地开发要起更多进程。所以单次执行只有几百毫秒、没有工具调用、日活很小的场景不该拆——那时候拆分带来的复杂度远大于收益。
  6. 可以预期的追问：不拆但用线程池或者子进程行不行？答案是能缓解「挤占」但解决不了「重启即丢失」和「多实例状态不共享」，因为那两件事的根因是状态在进程里，不是并发模型不对。

  How to reason about it · think before answering

  1. The hinge is the second half. Answering only 'decoupling and scalability' sounds copied from a textbook; the interviewer wants to know which concrete symptom forced you to split, and what splitting costs.
  2. Offer a reusable chain: one agent run is long and unpredictable (model latency plus several tool calls, seconds to tens of seconds), while the ingress path carries all traffic and must stay in the millisecond range. Put workloads three orders of magnitude apart in the same process and the slow one starves the fast one.
  3. Make the symptom concrete: a single process running a dozen long executions saturates connections and memory, health checks start timing out, the orchestrator declares the instance dead and restarts it, and every in-flight run dies with it. That story lands harder than any abstract argument.
  4. Then state the rule: anything a worker can do should not live in the gateway, which keeps only auth, rate limiting, persistence and dispatch — four steps with bounded latency. After the split the stateless gateway scales with traffic while worker concurrency is tuned against model quota; the two curves were never the same.
  5. Volunteer the cost, which is where candidates separate: the contract becomes 202 instead of 200 so clients need a second subscribe round trip, you now operate a bus and a runs table, tracing spans more hops, and local development needs more processes. So do not split when a run takes a few hundred milliseconds, uses no tools, and serves modest traffic.
  6. Expect the follow-up: could a thread pool or child processes do instead? They ease starvation but fix neither 'restart loses in-flight work' nor 'two instances cannot see each other's state', because the root cause is state living inside the process, not the concurrency model.

  答题要点

  • 一次 Agent 执行是几秒到几十秒的长任务，接入层是毫秒级短请求，两者同进程时长任务必然挤占短请求的资源
  • 单进程的三个具体死法：重启丢掉在途执行、多实例状态各存各的、长执行把健康检查拖超时导致实例被误杀
  • 判据是「能在 Worker 做的不放 Gateway」，接入层只留鉴权、限流、落库、投递
  • 拆开后 Gateway 无状态按流量扩容、Worker 按模型配额扩容，两条曲线可以独立调
  • 代价是接口从 200 变 202、多一次订阅往返、排障链路变长；单次执行仅几百毫秒且无工具调用的场景不该拆

  Key points

  • A run takes seconds to tens of seconds while ingress requests are millisecond-scale; in one process the long work starves the short work
  • Three concrete failure modes: restarts lose in-flight runs, multiple instances hold separate state, and long runs stall health checks so the orchestrator kills a healthy instance
  • The rule is that anything a worker can do stays out of the gateway, which keeps only auth, rate limiting, persistence and dispatch
  • After splitting, gateways scale on traffic and workers scale on model quota — two independent curves
  • Costs: a 202 contract plus a subscribe round trip, an extra bus and table to operate, longer traces; skip the split for sub-second runs with no tool calls

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

• Redis Streams 的 consumer group 是怎么工作的？为什么它既能做工作队列又能做发布订阅？How does a Redis Streams consumer group work, and why can it serve both as a work queue and as pub/sub?

  国内高频海外高频基础#message-bus#redis-streams

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

  1. 这题是概念题，区分度在于你有没有把「组」和「消费者」两层分清。只答「多个消费者一起消费」会被追着问「那同一条消息会不会被消费两次」，而这正是两层的区别所在。
  2. 先给两层结构：流本身只增不减，组挂在流上、维护一个读游标和一份 pending 清单，消费者挂在组上、只是组内的一个名字。同一个组内的消费者分摊消息（一条只进一个人），不同的组各自都能读到全量——工作队列和发布订阅就是这一个数据结构的两种用法。
  3. 接着点出 pending 清单（PEL）记了哪三件事：这条消息归哪个消费者、被投递过几次、最后一次投递在什么时刻。这三列分别对应「谁在处理」「要不要判成毒消息」「能不能被别人接手」，答出来就说明你真的读过文档而不只是抄过示例。
  4. 结论要落到分配规则上：组把消息分给谁，完全取决于谁先来问，没有任何亲和性。所以 consumer group 天然不保证「同一个用户的多条消息按顺序被同一个人处理」——这一句是把话题引向自己准备好的深水区。
  5. 可以预期的追问一：消费者的名字该怎么取？答：随机名会让进程重启后老名字下的未确认消息变成孤儿，只能靠 XAUTOCLAIM 捡回来，所以要么用有状态部署给的稳定序号，要么就必须依赖 XAUTOCLAIM 兜底，并定期用 XGROUP DELCONSUMER 清理不会再回来的名字。
  6. 可以预期的追问二：怎么保住同一个用户的顺序？答：在总线之上做分片——把用户 id 哈希到固定数量的分片，每个分片同一时刻只由一个消费者持有，顺序就回来了。消费组本身解决不了这件事。

  How to reason about it · think before answering

  1. This is a concept question; the discriminator is whether you separate the group layer from the consumer layer. Saying only 'several consumers read together' invites 'so is a message processed twice?' — and that is exactly what the two layers settle.
  2. Give the structure: the stream is append-only; a group sits on the stream and owns a read cursor plus a pending list; a consumer is just a name inside a group. Consumers in one group share the messages (each message goes to exactly one of them), while separate groups each see the full stream — one data structure, both a work queue and pub/sub.
  3. Then name the three things the pending entries list records: which consumer owns the message, how many times it has been delivered, and when it was last delivered. Those map to 'who is working on it', 'is it poison yet' and 'can someone else take over' — knowing them signals you read the docs, not just a snippet.
  4. Land on the dispatch rule: a group hands a message to whoever asks first, with no affinity at all. So a consumer group does not keep multiple messages from the same user in order on the same worker — say this yourself and you steer into ground you have prepared.
  5. Expect: how do you name consumers? Random names orphan the unacked messages of the previous name after a restart, recoverable only via XAUTOCLAIM. Either use stable ordinals from a stateful deployment, or rely on XAUTOCLAIM and periodically prune dead names with XGROUP DELCONSUMER.
  6. Expect: how do you preserve per-user order? Shard above the bus — hash the user id onto a fixed number of shards and let one consumer own a shard at a time. The consumer group cannot do this for you.

  答题要点

  • 流只增不减；组挂在流上，维护读游标和 pending 清单；消费者是组内的一个名字
  • 同组内消息被分摊（一条只进一个消费者），不同组各自拿到全量，所以同一个结构同时支持工作队列和发布订阅
  • pending 清单记三件事：归属的消费者、投递次数、最后一次投递时刻，分别用于接手、毒消息判定和超时检测
  • 分配没有亲和性，谁先来问给谁，所以不保证同一个用户的多条消息顺序，要在总线之上做分片
  • 消费者名字随机会在重启后留下孤儿消息，要么名字稳定，要么依赖 XAUTOCLAIM 并清理死名字

  Key points

  • The stream is append-only; a group holds a read cursor and a pending list; a consumer is a name within a group
  • Within a group messages are split (one message, one consumer); separate groups each get everything, so one structure covers both work queue and pub/sub
  • The pending list records owner, delivery count and last-delivery time — used for takeover, poison detection and timeouts
  • Dispatch has no affinity, so per-user ordering is not guaranteed and needs sharding above the bus
  • Random consumer names orphan unacked messages after a restart; use stable names or rely on XAUTOCLAIM plus XGROUP DELCONSUMER cleanup

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

• 为什么要对 userId 做哈希分片，而不是让消费组随机派发？分片数应该怎么选？Why hash user ids into shards instead of letting the consumer group dispatch freely, and how do you pick the shard count?

  国内高频海外高频基础#sharding#consistent-hashing#scalability

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

  1. 题眼在「为什么不随机派发」。只答「为了负载均衡」就掉进坑里了——消费组本来就是负载均衡，随机派发在均衡上比哈希分片更好。分片解决的是另一件事：亲和性。
  2. 推导链是这样的：消费组的分配单位是「一条消息」，而业务要求的最小串行单位是「一个用户」；单位对不上，同一个用户连发的两句话就会被两个进程同时处理。所以要把分配单位从消息抬到用户。
  3. 第二步是「为什么中间要垫一层 shard，而不是 userId 直接取模 worker 数」。因为 worker 数会变——扩容、重启、崩溃、滚动发布；除数一变，几乎所有用户的归属都会变，正在处理的会话被整体搬家。固定的 shard 数把「用户到 shard」钉死，只让「shard 到 worker」随伸缩浮动。
  4. 分片数怎么选，要给出可执行的判据而不是一个数字：它是并行度的上限（256 个 shard 最多让 256 个 worker 有活干），而且改它等于一次数据迁移（所有用户归属重算，必须停机或双写过渡）。所以宁可一开始定得偏大——256 摊在 3 个 worker 上是 85、85、86，多出来的成本只是几百个 key 的内存；定成 8 个的话扩到第 9 个 worker 就撞墙了。要用 2 的幂，取模能退化成位运算，也方便将来对半拆分。
  5. 主动说出哈希均匀的边界：均匀说的是「用户数均匀」，不是「消息量均匀」。一个日发千条的大客户可能和一千个散户落在同一个 shard 上。缓解是给大客户在哈希前加一张小的例外表、单独占一个 shard，而不是把总分片数调大（那就是上面说的数据迁移）。
  6. 可预期的追问：为什么不用一致性哈希？答案是它优化的是「节点变化时的迁移量」，前提是分片承载状态、搬迁很贵。我们的 worker 是无状态执行体，状态在数据库和 Redis 里，没有数据要搬；而且 shard 到 worker 的归属本来就由租约动态决定。固定分片优化的是可预测性，在这个场景里更简单，也更可靠。

  How to reason about it · think before answering

  1. The hinge is 'why not dispatch freely'. Answering 'for load balancing' misses it — a consumer group already balances load, and free dispatch balances better than hashing. Sharding buys something else: affinity.
  2. The chain: a consumer group's unit of assignment is one message, while the business requires one user as the smallest serial unit. When those units disagree, two messages from the same user get processed concurrently by two workers.
  3. Second step: why insert a shard layer instead of taking userId modulo the worker count? Because the worker count changes on scale-up, restart, crash and rolling deploy. Change the divisor and almost every user is remapped, so in-flight sessions migrate wholesale. A fixed shard count pins user-to-shard and lets only shard-to-worker float.
  4. For the count, give criteria rather than a number: it caps parallelism (256 shards means at most 256 useful workers), and changing it is a data migration (every user is remapped, requiring downtime or a dual-write transition). So oversize it up front — 256 across 3 workers is 85/85/86 and costs a few hundred keys of memory, while picking 8 walls you in at the ninth worker. Use a power of two so the modulo degrades to a bit mask and future splits stay clean.
  5. Volunteer the limit of uniformity: it means uniform user counts, not uniform message volume. One enterprise account sending a thousand messages a day can share a shard with a thousand one-message users. The fix is an exception table before the hash that gives that account its own shard, not a larger shard count — that would be the migration above.
  6. Expect the follow-up: why not consistent hashing? It optimizes remap volume, which pays off when shards carry state that is expensive to move. Our workers are stateless executors with state in Postgres and Redis, so nothing needs moving, and shard ownership is already decided dynamically by leases. Fixed sharding optimizes predictability, which is simpler and more reliable here.

  答题要点

  • 分片解决的是亲和性不是负载均衡：把分配单位从「一条消息」抬到「一个用户」，同一个用户永远落到同一个 worker
  • 中间垫一层固定 shard，是为了让 worker 伸缩时用户到 shard 的映射保持不变，只有 shard 到 worker 的归属浮动
  • 分片数是并行度上限，改它等于一次数据迁移，所以一开始就定偏大、用 2 的幂（本课 256）
  • 哈希均匀保的是用户数均匀，不是消息量均匀；大客户热点要靠哈希前的例外表单独拆 shard
  • 一致性哈希优化迁移量，只在分片带状态时划算；无状态 worker 用固定分片更简单

  Key points

  • Sharding is about affinity, not balancing: it lifts the unit of assignment from one message to one user so a user always lands on the same worker
  • The fixed shard layer keeps user-to-shard stable across scaling; only shard-to-worker ownership moves
  • The shard count caps parallelism and changing it is a migration, so oversize it and use a power of two (256 in this course)
  • Uniform hashing means uniform user counts, not uniform traffic; hot accounts need an exception table before the hash
  • Consistent hashing optimizes remap volume and only pays off for stateful shards; stateless workers do better with fixed shards

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

• 怎么设计一次 Agent 执行（run）的状态机？需要覆盖哪些异常状态？How would you design the state machine for one agent run, and which failure states must it cover?

  国内高频海外高频基础#state-machine#distributed-systems

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

  1. 这题的区分度不在「能不能列出几个状态」，而在你有没有说出「为什么单进程时代不需要它」。答不出这一点，说明你只是抄过一张状态图。
  2. 先给动机：单进程里「执行到哪一步了」就是那个函数栈，状态存在于进程内存里，不需要名字。拆成 Gateway 与 Worker 之后，至少三方要同时回答同一个问题——接入层要判断还挂不挂 SSE，执行层要判断这条消息是否已被人领走，前端重开页面要判断上次的问题还在不在生成。三方不同进程，只能靠一张表对齐。
  3. 再给状态：pending 到 running 到 streaming 到 done 是正常路径，failed（重试耗尽）与 cancelled（被打断合并或用户取消）是两个随时可以走的异常出口。主动说明为什么 running 和 streaming 要分开：前者是「有人领走了但还没有一个字」，后者是「第一个字已出来」，这条线就是首字延迟的观测点，也是前端决定转圈还是打字机的依据。
  4. 结论要落到「状态机是用来挡写入的」：终态没有出边这一条最值钱。至少一次投递下「已经 done 的 run 又收到一个片段」是常态，没有转换表，那一笔会安静地写进库，用户看到回复末尾多出半句话，而日志里查不出是谁写的。
  5. 补一条纪律，这是有没有落地过的分水岭：所有写状态的地方都必须过同一个转换函数。绕过它直接执行一条更新语句，状态机就退化成注释了。
  6. 可以预期的追问：状态存哪、并发怎么办？答数据库那一行是唯一真相，转换用带条件的更新（更新时把当前状态写进 where 子句），失败说明有人抢先改过，这时候重读再决定，而不是覆盖。

  How to reason about it · think before answering

  1. The discriminator is not listing states, it is explaining why a single-process service does not need them at all. Without that, you have only memorized a diagram.
  2. Start from motivation: in one process the call stack *is* the state. Once you split gateway and worker, three parties must answer the same question independently — the gateway decides whether to keep an SSE connection open, the worker decides whether someone already claimed the message, and a reopened browser tab asks whether the previous question is still generating. Different processes, so the answer has to live in a table.
  3. Then the states: pending to running to streaming to done on the happy path, with failed (retries exhausted) and cancelled (superseded by a merge, or user-cancelled) as exits available from anywhere. Volunteer why running and streaming are separate: running means claimed but no token yet, streaming means the first token is out. That boundary is your time-to-first-token probe and the frontend's cue to switch from spinner to typewriter.
  4. Land on the real purpose: the machine exists to reject writes. Terminal states having no outgoing edges is the most valuable row in the table. Under at-least-once delivery, a done run receiving one more chunk is routine, and without the table that chunk lands silently — the user sees half a sentence appended and the logs show nothing wrong.
  5. Add the discipline that separates shipped from read-about: every status write goes through one transition function. One raw UPDATE that bypasses it and the state machine is just a comment.
  6. Expect the follow-up on storage and concurrency: the database row is the single source of truth, and transitions are conditional updates that include the expected current status in the WHERE clause. Zero rows affected means someone moved first — re-read and decide, never blindly overwrite.

  答题要点

  • 单进程里状态就是函数栈；拆成 Gateway 与 Worker 后有三方要独立回答「这次执行到哪了」，必须落成一张表
  • 正常路径 pending 到 running 到 streaming 到 done；异常出口 failed（重试耗尽）与 cancelled（打断合并或用户取消）
  • running 与 streaming 分开，是为了观测首字延迟，也让前端知道该转圈还是该开始打字机效果
  • 终态没有出边是核心：至少一次投递下的迟到片段会被当场挡住，而不是安静写进库
  • 纪律：所有状态写入都过同一个转换函数，并用带当前状态条件的更新来处理并发

  Key points

  • In one process the call stack is the state; after splitting gateway and worker, three parties need the same answer, so it has to be a table
  • Happy path pending, running, streaming, done; exits are failed (retries exhausted) and cancelled (merged or user-cancelled)
  • Separating running from streaming gives you a time-to-first-token probe and tells the UI when to switch from spinner to typewriter
  • Terminal states with no outgoing edges reject the late chunks that at-least-once delivery guarantees you will get
  • Every status write goes through one transition function, implemented as a conditional update on the expected current status

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

• 为什么 Agent 需要额外的长期记忆，而不是把历史全部塞进上下文？Why does an agent need a separate long-term memory instead of stuffing all history into the context window?

  国内高频海外高频基础#long-term-memory#rag#cost

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

  1. 这题最容易答成「因为窗口装不下」。那只答对了一半，而且是不值钱的那一半——窗口一年比一年大，光靠这条理由，面试官会追问「等窗口到一百万 token 呢」，你就没词了。
  2. 先把两个问题拆开：上下文压缩解决的是「同一次会话里这一轮塞不下」，长期记忆解决的是「上个月说过的事想不起来」。前者在组装请求时做减法，后者做加法，触发时机、数据去向、失败后果都不同。能主动区分这两件事，是这题最大的区分度。
  3. 然后给成本账：200 条记忆、每条约 400 token 就是 8 万 token，按输入价 0.15 美元每百万 token 算，每一轮多付 0.012 美元；一天 20 轮就是 0.24 美元一个用户。只检索最相关的 5 条是 2000 token、每轮 0.0003 美元，差 40 倍。而且这笔钱是每轮重复付的，不是一次性的。
  4. 再给比钱更硬的理由：无关信息会降低命中率。200 条里跟这一轮相关的可能只有 1 条，剩下 199 条是噪声，模型会被带偏去回答一个用户没问的问题。**所以哪怕窗口无限大、token 免费，也该检索而不是全塞。** 这一句是这题的最优解。
  5. 落到做法上：把跨会话的用户事实与偏好抽成陈述句存进向量库，每轮按语义检索最相关的三五条注入请求——这就是 RAG 最小的一环。
  6. 可以预期的追问：什么信息该进长期记忆？答三问——跨会话之后还需要吗、会不会随时间失效、能不能靠检索捞回来。「用户住上海」三条都满足，「把刚才那段改成三句话」一条都不满足。

  How to reason about it · think before answering

  1. The tempting answer is 'the window is too small'. That is half right and it is the cheap half — windows keep growing, and the interviewer will ask what you would do at a million tokens.
  2. Separate the two problems first: context compression solves 'this turn does not fit in one session', long-term memory solves 'I cannot recall what was said last month'. One subtracts at request-assembly time, the other adds. Naming that distinction unprompted is where the signal is.
  3. Then quantify: 200 memories at roughly 400 tokens each is 80k tokens; at 0.15 USD per million input tokens that is 0.012 USD every single turn, about 0.24 USD per user per day at 20 turns. Retrieving the top 5 is 2k tokens, 0.0003 USD per turn — a 40x gap, and it repeats every turn.
  4. Give the reason that beats cost: irrelevant context lowers accuracy. If one of 200 memories is relevant, the other 199 are noise that pull the model toward answering something nobody asked. So even with an infinite free window, you would still retrieve rather than dump.
  5. Land on practice: distil cross-session user facts and preferences into standalone statements, store them as vectors, and inject the three to five most relevant per turn — the minimal form of RAG.
  6. Expect the follow-up: what belongs in long-term memory? Three tests — is it still needed across sessions, does it expire, can retrieval find it again. 'Lives in Shanghai' passes all three; 'shorten that paragraph' passes none.

  答题要点

  • 压缩管「这一轮塞不下」，长期记忆管「上个月说过的事想不起来」，是两个问题、两套机制
  • 全塞的成本是每轮重复付的：200 条约 8 万 token，每轮多 0.012 美元；检索 5 条只要 0.0003 美元
  • 更硬的理由是准确率：无关记忆是噪声，会把模型带偏，所以窗口再大也该检索而不是全塞
  • 做法是把跨会话的事实抽成陈述句、向量化存储，每轮按语义检索最相关的三五条注入
  • 判断一条信息该不该进长期记忆：跨会话还需要吗、会不会失效、能不能被检索到

  Key points

  • Compression handles 'this turn does not fit'; long-term memory handles 'what did they say last month' — different problems, different machinery
  • Dumping everything costs on every turn: 200 memories is about 80k tokens and 0.012 USD per turn versus 0.0003 USD for five retrieved ones
  • The stronger reason is accuracy — irrelevant memories are noise, so you would retrieve even with an infinite window
  • Practice: distil cross-session facts into statements, embed them, inject the top three to five per turn
  • Admission test for a memory: still needed across sessions, does not expire, and is findable by retrieval

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

• 服务部署了多个实例，定时任务为什么不能让每个实例各自起一个 cron？你会怎么做？When a service runs multiple replicas, why not let each replica start its own cron? What would you do instead?

  国内高频海外高频基础#scheduling#distributed-systems#cost

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

  1. 题眼在「多个实例」四个字。只答「会重复执行」拿不到分，因为那是现象；面试官想看你能不能把现象换算成业务后果和钱。
  2. 先把重复的代价说具体：3 个副本各起 cron，同一个任务被执行 3 次，用户收到 3 份一样的推送，你付 3 份模型调用的钱。而且这个倍数会跟着副本数走——扩容到 10 个副本，账单和骚扰量一起变成十倍，却不会触发任何告警，因为从每个进程自己的视角看它只是老实地执行了一次。
  3. 然后给出正确的形状：把「谁该在什么时候被执行」收进一个中心调度器，它命中 cron 之后只做一件事——往消息总线投递一条任务消息；执行侧照旧靠消费组分摊，一条消息只会被一个消费者拿到。关键认知是「定时任务不是一种新的执行方式，只是把按按钮的人从用户换成了钟表」，所以执行侧一行代码都不用改。
  4. 接着主动补上「那调度器自己不就成单点了吗」——这是必被追问的一句。答案分两层：调度器无状态、崩了拉起来就行，短暂不可用的代价只是几分钟内的任务延迟；真要高可用就起两个实例，靠投递时的幂等键去重，而不是靠给调度器加分布式锁。
  5. 最后点一句选型：任务量不大时中心调度器加消息总线足够；量大或者任务本身有依赖关系时，业界会换成专门的调度框架（带任务依赖、重试策略、补数），但底层的「中心决定 + 队列分发」结构是一样的。
  6. 可以预期的追问：调度器崩溃 90 秒，中间跨过的那一分钟怎么办？答启动时回看最近 N 分钟逐分钟重放，因为有幂等键兜底，重复投递无害——这正是 at-least-once 加幂等这组搭配能成立的地方。

  How to reason about it · think before answering

  1. The hinge is the phrase multiple replicas. Saying it would run twice is only the symptom; the interviewer wants the business and dollar consequence.
  2. Make the cost concrete: three replicas each running cron means the job fires three times, users get three identical pushes, and you pay for three model calls. The multiplier tracks replica count, so scaling to ten makes both the bill and the spam tenfold, with no alert firing, because from each process's own point of view it ran exactly once.
  3. Give the right shape: move the decision of who runs when into one central scheduler whose only job, on a cron match, is to publish a task message onto the bus; the execution side keeps using a consumer group so one message reaches exactly one consumer. The key insight is that a scheduled task is not a new execution path, it just swaps the user for a clock as the thing pressing the button, so the worker code stays untouched.
  4. Volunteer the obvious follow-up: doesn't the scheduler become a single point of failure? Two layers. It is stateless, so a crash costs you a few minutes of task delay; if you truly need HA, run two instances and dedupe on the idempotency key at publish time rather than bolting a distributed lock onto the scheduler.
  5. Close with sizing: a central scheduler plus a bus is enough at modest volume. At high volume, or when tasks have dependencies, teams move to a dedicated workflow scheduler with dependency graphs, retry policy and backfill, but the underlying central-decision-plus-queue shape is identical.
  6. Expect: the scheduler was down for 90 seconds and skipped a minute — now what? Replay the last N minutes on startup, one minute at a time. The idempotency key makes redundant publishes harmless, which is exactly what makes at-least-once plus idempotency the easy combination.

  答题要点

  • 每个实例各自起 cron 等于同一个任务被执行 N 次：用户收到 N 份重复推送，模型调用花 N 倍的钱，倍数随副本数线性增长且不会触发告警
  • 正确形状是中心调度器命中 cron 后只往消息总线投递一条消息，执行侧靠消费组保证一条消息只被一个 Worker 拿到
  • 定时任务不是新的执行路径，只是把触发者从用户换成了钟表，所以 Worker 侧不需要任何改动
  • 调度器是无状态的，崩了拉起来即可；需要高可用就起两个实例靠投递时的幂等键去重，不要给它加分布式锁
  • 崩溃期间跨过的时间点靠启动时回看最近 N 分钟重放补上，幂等键保证重复投递无害

  Key points

  • Per-replica cron means the job runs N times: N duplicate pushes, N times the model spend, scaling linearly with replica count and silently
  • The right shape is a central scheduler that publishes one message to the bus on a cron match, with a consumer group ensuring exactly one worker picks it up
  • A scheduled task is not a new execution path — only the trigger changed from a user to a clock, so worker code is unchanged
  • The scheduler is stateless: restart on crash, and if you need HA run two and dedupe on the idempotency key rather than adding a distributed lock
  • Missed minutes are recovered by replaying the last N minutes at startup, which is safe because the idempotency key absorbs duplicates

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

• 怎么设计 dev 与 prod 的隔离，防止本地开发影响线上数据？How do you isolate dev from prod so local development cannot touch production data?

  国内高频海外高频基础#operations#security#configuration

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

  1. 这题看着基础，但它筛的是「有没有踩过」。踩过的人第一句会说事故形态，没踩过的人第一句说「用不同的配置文件」。
  2. 先说事故形态：同一套代码、经常还是同一个 Redis，你在本机起一个 Worker 调试，它连的却是线上那条流，把真实用户的消息捞走执行了。**这类事故没有任何报错，两边日志都显示一切正常**——从代码角度看它确实老老实实处理了一条消息。正因为没有报错，它可能持续很久才被发现。
  3. 然后按成本分层给方案：命名空间（同一套基础设施，键名带前缀）、独立实例（各自的 Redis 与数据库）、独立环境（网络、凭证、账号全分开）。生产系统最终要走到第三层，但第一层成本最低也最容易漏，所以是重点。
  4. 第一层的关键实现细节是拿分点：前缀只能在一个函数里拼。散落到各处去拼字符串，二十个键名里漏掉一个就等于没隔离，而漏掉的那个通常是最新加、最没被测过的功能。这一点比「要加前缀」本身更能体现工程经验。
  5. 再补三件必须一起做的事：凭证分开（本机那把 key 只能连开发库，配置写错也波及不到线上）；破坏性操作要认环境（清库、重放死信、重算索引这类脚本第一行先读环境变量，生产上要求显式确认）；生产禁止降级实现（离线用的内存实现在生产上一旦因配置疏漏被走到，进程会安静起来、各自在自己内存里干活，健康检查还全是绿的，这类故障能藏好几个小时——启动时直接报错退出比事后排查便宜得多）。
  6. 可以预期的追问：为什么不干脆只用独立实例，省掉前缀这一层？答：独立实例解决的是「连错了地址」，前缀解决的是「连对了地址但走错了命名空间」——两者失效的方式不同。而且前缀几乎零成本，在共享测试环境、多人并行开发时还能顺带隔离每个人的数据。防御要分层，最便宜那层没理由不做。

  How to reason about it · think before answering

  1. This looks basic, but it screens for whether you have been burned. People who have start with the failure shape; people who have not start with use different config files.
  2. Describe the failure: same codebase, often the same Redis, and you start a worker locally to debug — except it is connected to the production stream and it claims and executes a real user's message. There is no error anywhere and both sides log business as usual, because from the code's point of view it did dutifully process one message. Precisely because nothing errors, this can run for a long time before anyone notices.
  3. Then give layered options by cost: namespacing (shared infrastructure, prefixed keys), separate instances (its own Redis and database), and separate environments (network, credentials, accounts all split). Production eventually wants the third layer, but the first is the cheapest and the easiest to get wrong, so that is where the focus belongs.
  4. The implementation detail in layer one is where the points are: the prefix may only be assembled in one function. Scatter string concatenation around the codebase, miss one key out of twenty, and you have no isolation at all — and the one you missed is usually the newest, least tested feature. This point signals real experience more than add a prefix does.
  5. Add three companions. Split credentials, so the local key can only reach the dev database and a misconfiguration cannot reach production. Make destructive operations environment-aware: scripts that truncate tables, replay dead letters or rebuild indexes read the environment variable on their first line and demand explicit confirmation in production. And forbid fallback implementations in production: if a config slip makes production take the in-memory path, processes come up quietly, each working in its own memory, with every health check green — that kind of fault hides for hours, so failing fast at startup is far cheaper than diagnosing it later.
  6. Expect: why not just use separate instances and skip prefixes? Because separate instances solve connected to the wrong address while prefixes solve connected to the right address but the wrong namespace — the two fail differently. Prefixes are also nearly free, and they incidentally isolate each developer's data in a shared test environment. Defence should be layered, and there is no reason to skip the cheapest layer.

  答题要点

  • 先说事故形态：本机 Worker 连上线上流，把真实用户消息捞走执行，且两边日志都显示正常、没有任何报错，所以能藏很久
  • 按成本分三层：命名空间（键名前缀）、独立实例（各自 Redis 与库）、独立环境（网络凭证账号全分开）
  • 前缀只能在一个函数里拼——散落各处漏掉一个键就等于没隔离，而漏掉的通常是最新加、最没测过的功能
  • 凭证分开，本机 key 只能连开发库；破坏性脚本第一行读环境变量并在生产要求显式确认
  • 生产禁止降级到内存实现：配置疏漏时进程会安静起来、健康检查全绿，故障能藏几小时，应在启动时直接报错退出
  • 独立实例防「连错地址」、前缀防「地址对了但命名空间错了」，失效方式不同，最便宜那层没理由不做

  Key points

  • Lead with the failure shape: a local worker attached to the production stream claims and runs a real user's message, with normal logs on both sides and no error, so it hides for a long time
  • Three layers by cost: namespacing (key prefixes), separate instances (own Redis and DB), separate environments (network, credentials, accounts)
  • The prefix must be assembled in exactly one function — scattered concatenation misses one key and voids the isolation, usually the newest and least tested feature
  • Split credentials so the local key only reaches dev; destructive scripts read the environment first and require explicit confirmation in production
  • Forbid the in-memory fallback in production: on a config slip processes come up quietly with green health checks and the fault hides for hours — fail fast at startup instead
  • Separate instances prevent wrong address, prefixes prevent right address wrong namespace — different failure modes, and the cheapest layer is free