面试题库

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

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
• 在一个多 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