分布式基础理论面试题:网络失败、CAP、一致性、共识与幂等
本页只保留标准回答和原理入口,详细推导、流程图、Demo与排查见对应知识页。
| 问题 | 标准回答 | 原理页 |
|---|---|---|
| 远程调用和本地调用最大区别 | 远程调用存在请求未到、执行中、已提交但响应丢失等无法仅从超时区分的状态;因此需要Deadline、幂等、查询确认、补偿和对账。 | 网络失败基础 |
| CAP是不是三选二 | 不是。网络分区发生时系统必须在特定操作上选择继续提供可能不一致的服务,或拒绝/等待以保护一致性;没有分区时仍可同时追求一致和可用。 | CAP |
| BASE是什么 | Basically Available、Soft State、Eventually Consistent,表示用显式中间状态、重试、补偿和对账换取可用性,不是放弃一致性。 | BASE |
| 强一致和最终一致区别 | 强一致让成功写后读取遵守定义的最新可见规则;最终一致允许无新更新时副本最终收敛。具体还要区分线性一致、顺序一致和会话保证。 | 一致性模型、数据一致性 |
| 读己之写和单调读是什么 | 读己之写保证客户端能看到自己的成功写;单调读保证看到新版本后不再退回旧版本,常通过主站粘性、位点或版本实现。 | 一致性设计 |
| Quorum为什么需要多数派 | 严格多数集合必有交集,配合任期、日志新旧和持久化规则,使两个冲突值不能同时合法提交。 | 多数派 |
| Raft一次写怎样提交 | Leader追加日志并复制,获得多数派匹配后推进commit index,各节点按序Apply;客户端超时仍可能是已提交但响应丢失。 | Raft |
| ZAB和Raft区别 | 都以Leader和多数派复制有序日志;ZAB围绕ZooKeeper的恢复与原子广播,Raft把选举、复制和安全规则拆得更易理解,不能只按名词一一等同。 | 共识对比、ZAB |
| 幂等是什么 | 同一业务意图重复执行只产生一次业务效果,并返回与第一次相容的结果;它通过稳定业务键、唯一约束、状态机和结果记录实现。 | 幂等 |
| 为什么先查再插不安全 | 两个并发请求都可能查到不存在,再同时执行副作用;应先用唯一约束或条件更新原子抢占处理权。 | 并发竞态 |
| traceId能作为幂等键吗 | 通常不能。traceId标识一次调用链,重试可能产生新Trace;幂等键应标识稳定业务意图并跨重试不变。 | 幂等键 |
| MQ消费怎样幂等 | 用eventId和消费者作用域唯一键,在同一本地事务中完成消费占位、业务写入和结果记录,提交后再ACK。 | MQ幂等 |
| 缓存和数据库怎样保持一致 | Cache Aside常在数据库事务提交后删除缓存,删除失败进入可靠重试和补偿,TTL兜底;关键事实仍以数据库为准。 | 缓存一致性 |
| 分布式锁能替代幂等吗 | 不能。锁可能过期、故障切换或脑裂,且只控制并发入口;最终正确性仍需唯一约束、状态机、Fencing和补偿。 | 锁边界 |
| 限流、熔断和降级区别 | 限流按容量拒绝超额流量,熔断在下游持续失败或慢时阻断调用,降级决定业务返回什么。 | 限流、稳定性 |
项目回答模板
我会从网络不可靠和状态分散开始设计:同步写调用设置端到端Deadline,超时进入结果未知并按业务流水查询;Provider用唯一约束和状态机幂等。跨服务数据按风险选择XA/TCC/Saga或Outbox,异步消费者同事务去重后ACK。共识组件只负责控制面状态顺序,不替代业务事务;缓存、ES和通知通过重试、补偿和对账最终收敛。
本章小结
基础理论面试要把CAP、共识和幂等落回具体失败窗口,不能只背定义。
