题目重点：Enterprise 初筛问机器之间如何沟通；按请求响应、异步交付和共享状态比较延迟、失败、顺序与背压。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景是两个不同主机的服务交换消息，网络可能延迟、重复、丢连接或分区；业务所需一致性尚未指定。
- ‘机器内部’若确指单机进程/线程沟通，应改谈 pipe、Unix socket、共享内存、线程 channel；不能把跨机 RPC 当成唯一原题含义。
- 方案选择需要先明确同步响应、吞吐、消息大小、持久化与顺序要求。
解题路线
- 同步请求响应：HTTP/gRPC/TCP 等网络协议提供一次请求与响应关联，适合需要即时答案的查询/命令；超时不能推出远端未执行，重试写操作需幂等键或结果查询。
- 异步消息：队列/日志解耦生产者与消费者，可缓冲峰值、重试和重放；必须明确至少一次交付下去重、分区顺序、死信队列和积压告警。
- 共享存储：双方通过数据库/对象存储交换状态，适合可持久查询的工件；读写需版本、事务或 CAS，轮询会增加延迟，不能把数据库当零成本消息总线。
- 大 payload 可把元数据走 RPC/队列、内容放对象存储；流式传输须考虑分块校验、背压和取消。安全上需服务身份、传输加密与授权，观测要有 request ID、延迟和重试指标。
- 先问面试官‘机器内部’指同一主机 IPC 还是不同机器通信，再选一例画出发送、确认、失败重试与收端处理状态。
手动走一遍
训练例：A 让 B 执行一次批处理。若 A 需要立刻知道受理状态，用带 idempotency key 的 RPC；若 B 可能忙数分钟，则 A 向队列发任务并返回 job ID，B 消费并把结果存储，A 查询状态。A 的 RPC 超时后直接重发而无幂等键，可能执行两次。
规模与取舍
单次 RPC 至少一次网络往返，延迟约网络 RTT 加排队与处理；队列增加持久化与消费延迟，但可把峰值流量转成积压；共享存储每次读写承担存储往返和一致性成本。具体吞吐与规模取决于 payload、分区数及实现，题目没有数值。
易错点与追问
容易失分的边界
- 只列 TCP/UDP/HTTP 名词，不说明业务交付语义。
- 认为 RPC 超时等于服务端未执行。
- 把队列的至少一次重投当成恰好一次业务效果。
- 忽略‘机器内部’可能是单机 IPC 的题意歧义。
继续深挖
- 若要求同一 user 的命令有序，队列如何分区？
- 何时选共享内存/Unix socket 而非网络 RPC？
- 消费者慢时如何背压与限制队列长度？
- 网络分区期间如何处理需要强一致的写入？
