For AI agents: the complete documentation index is available at https://tingfeng347.github.io/windwiki/llms.txt, the full documentation bundle is available at https://tingfeng347.github.io/windwiki/llms-full.txt, and this page is available as Markdown at https://tingfeng347.github.io/windwiki/terminology/backend-distributed.md.

后端与分布式 · 面试清单

面试权重：★★★★★　社招与后端岗的高频深水区；因为「大概会」和「真的做过」的差别很明显，追问会一直往下钻。

一、理论基础

术语	一句话释义
CAP	分区容错（P）必然发生，所以真正的取舍是分区发生时保一致性还是保可用性
CA 为什么不存在	只要系统跨网络，分区就无法排除；宣称「选 CA」等于假设网络永不出错
CP vs AP 举例	CP：etcd、ZooKeeper、HBase；AP：Cassandra、DynamoDB、Eureka
FLP 不可能性定理	在异步网络中只要有一个进程可能崩溃，就无法保证确定性地达成共识
FLP 为什么可绕过	现实网络不是纯异步，用超时/随机化把问题转为「以概率 1 达成」
ACID	原子性、一致性、隔离性、持久性，是单个事务内的保证
BASE	基本可用、软状态、最终一致，是分布式系统在可用性优先下的实践准则
ACID vs BASE	强一致但难扩展 vs 最终一致但可水平扩展；不是谁取代谁，而是按业务选择
最终一致性	不再写入后，经过有限时间所有副本收敛到同一值；关键要能说明「多久」
两将军问题	不可靠信道上无法 100% 确认双方一致，是分布式共识难度的根源
拜占庭容错	容忍节点作恶或撒谎；非拜占庭场景（节点只故障不作恶）用 Raft 就够

二、一致性模型

术语	一句话释义
强一致性（线性一致）	所有操作看起来在单一时间点上原子完成，最严格也最贵
顺序一致性	所有进程看到同一全局顺序，但不要求与真实时间对齐
因果一致性	有因果关系的操作保持顺序，无因果的可任意排序；比顺序一致弱但实用
最终一致性	只保证最终收敛，不保证中间读取看到什么
单调读	同一客户端不会读到「更旧」的数据，避免时间倒流
单调写	同一客户端的写按发出顺序生效（会话保证）
读己之写	用户写完立刻能读到自己的修改，主从架构下最常被破坏的保证
会话一致性	把读写放进同一会话以保证上述几种保证，是工程上最常用的折中
Quorum 读写	W + R > N 即可读到最新值，如 N=3、W=2、R=2；读多写少可调 W=1、R=3
向量时钟	用各节点计数向量判定事件的因果先后与并发冲突
逻辑时钟 vs 物理时钟	Lamport 时钟给全序但无真实时间；物理时钟有真实时间但会漂移
TrueTime	Google Spanner 用 GPS + 原子钟给出「有误差界的时间区间」，把不确定变成等待
HLC 混合逻辑时钟	把物理时间与逻辑计数结合，兼顾近似真实时间与因果，被多数 NewSQL 采用
可串行化快照隔离 SSI	PostgreSQL 的做法：快照读 + 冲突检测，比纯锁的串行化更实用

三、共识算法

术语	一句话释义
共识要解决的问题	多个节点对同一值达成一致，且能容忍部分节点故障
Paxos	理论基础，分 Prepare/Accept 两阶段；Multi-Paxos 用主提案人优化流水线
Raft	把问题拆成选主、日志复制、安全性三块；可理解性优先，工程落地最多（etcd、TiKV）
ZAB	ZooKeeper 的原子广播协议，与 Raft 相似但顺序保证的语义略有差异
PBFT	实用拜占庭容错，需 3f+1 个节点，用于联盟链等需容忍作恶的场景
Leader / Follower / Candidate	Raft 三种角色；只有 Leader 接受写请求
任期 Term	逻辑时间，每次选主递增，用来拒绝过期 Leader 的请求
多数派提交	日志被多数节点复制后才算提交，是「已提交不丢」的保证来源
选举超时与随机化	超时后随机会触发选举，随机化避免平票活锁
脑裂 Split-Brain	网络分区导致出现两个 Leader；靠多数派 + 任期号防住旧 Leader 提交
租约 Lease	Leader 在租约期内独占写权限，避免频繁选举；依赖时钟
见证者 Witness	只投票不存数据，用较便宜的方式凑出奇数多数派
etcd 的定位	集群配置与选主的事实标准；部署 3 或 5 节点，跨机房要考虑延迟

四、分布式事务

术语	一句话释义
为什么分布式事务难	跨节点没有全局锁与全局时钟，网络还会超时或丢包
2PC 两阶段提交	Prepare 全票通过才 Commit，同步阻塞、协调者单点、Prepare 后宕机数据不一致
3PC	在 2PC 前加 CanCommit 缩短阻塞窗口，但引入了新的不一致场景，工程上少用
TCC	Try 预留资源 → Confirm 确认 → Cancel 回滚；业务侵入强、隔离性最好
空回滚 / 悬挂 / 幂等	TCC 的三大坑：Cancel 先于 Try 到达、Try 迟到于 Cancel 之后、重复调用
Saga	长事务 = 多个本地事务 + 补偿操作；编排式（集中状态机）或协同式（事件驱动）
Saga 的隔离性	无隔离，需靠语义锁或状态机防止中间态被读到
本地消息表	业务与消息同库同事务落表，再由定时任务投递，简单可靠但有一致性延迟
事务消息	RocketMQ 半消息 + 回查机制，把「确认投递」交给 MQ 保证
最大努力通知	反复重试直到成功或放弃，适用于对账、通知类弱一致场景
可靠消息最终一致	「本地事务 + 消息」是互联网最主流的方案，核心是保证消息不丢不重
Seata 四种模式	AT（自动补偿、无侵入）、TCC、Saga、XA；AT 靠 undo log 反向补偿
柔性事务	放弃强隔离、用重试与补偿达成最终一致的一类事务的统称
什么时候不用分布式事务	能把事务收进单库就收进去，或改成异步 + 对账，往往比引入框架更稳
对账 Reconciliation	定时比对双方流水，把不一致暴露并修复——最终一致性系统的必备兜底

五、幂等与并发控制

术语	一句话释义
幂等 Idempotency	同一操作执行一次与多次结果相同，是重试与消息投递的前提
幂等键 Idempotency Key	由调用方生成的唯一标识（如订单号），服务端凭它去重
去重表	把幂等键写进唯一索引表，插入冲突即表示已处理
唯一索引兜底	最可靠的幂等实现方式，比任何代码判断都稳
状态机幂等	只允许合法状态跃迁，重复请求因状态不符被自然拒绝
乐观锁	用版本号或 CAS 更新，冲突就重试；适合冲突少的场景
悲观锁	先锁后改（`SELECT FOR UPDATE`），简单但并发差、易死锁
分布式锁	跨进程互斥；Redis 用 `SET NX PX` + Lua 释放，ZK 用临时顺序节点
锁的续期与看门狗	业务未完成时自动延长锁；否则会出现「锁过期了业务还在跑」
Redlock 的争议	多节点多数派加固，但仍依赖时钟假设，安全性存在理论争议
分布式锁 vs 幂等	锁是防并发重复执行，幂等是让重复执行无害；生产更该优先保证幂等

六、缓存与流量治理

术语	一句话释义
Cache Aside	读未命中查库回填，写时先更新库再删缓存，是最主流的缓存模式
缓存一致性难点	并发下「更新库 + 删缓存」仍有窗口被旧值回填，靠延迟双删或 binlog 订阅缓解
缓存穿透 / 击穿 / 雪崩	查不存在的数据 / 热点 key 失效瞬间 / 大量 key 同时失效或缓存整体挂掉
限流	主动限制进入系统的流量，保护自身；算法有计数器、滑动窗口、漏桶、令牌桶
漏桶 vs 令牌桶	漏桶恒定速率输出（整形），令牌桶允许突发（更贴合真实流量）
分布式限流	基于 Redis + Lua 的令牌桶或滑动窗口，注意 Redis 单点与本地兜底
熔断 Circuit Breaker	依赖失败率超阈值后直接快速失败，避免拖垮自身；状态为关闭/打开/半开
降级 Degradation	依赖不可用时返回兜底数据或关闭非核心功能
隔离 Bulkhead	线程池/信号量按依赖隔离，一个依赖慢不会耗尽所有资源
超时与重试	超时必须有，且上层超时要大于下层；重试要配指数退避 + 抖动
重试风暴 / 雪崩	故障时大量重试把下游压垮；靠退避、抖动、熔断与重试预算克制
抖动 Jitter	在退避时间上叠加随机量，避免重试在同一时刻对齐
背压 Backpressure	下游处理不过来时反向告知上游降速，而不是无限缓冲
舱壁模式 vs 熔断	前者限制爆炸半径，后者快速止损，通常一起用

七、工程实践

术语	一句话释义
分布式 ID 要求	全局唯一、趋势递增、高性能、高可用，最好还能反解时间
Snowflake	64 位：时间戳 + 机器 ID + 序列号；依赖时钟，必须处理回拨
时钟回拨的处理	等待追平、报警拒绝服务、或用备用位/延长位缓冲
号段模式	从数据库批量取一段 ID 在内存分配，性能高、依赖 DB 但压力小
UUID	无需协调但无序，作主键会导致 B+ 树随机插入与页分裂
消息队列的作用	异步解耦、削峰填谷、广播；代价是最终一致与运维复杂度
消息不丢的三个环节	生产端确认、Broker 持久化与副本、消费端手动 ACK；任一处缺失都会丢
重复消费与幂等	MQ 通常保证至少一次，业务侧必须幂等
顺序消息	同一业务键路由到同一分区/队列，并单线程消费；全局有序代价极高
死信队列	多次重试仍失败的消息落到 DLQ，供人工排查而不阻塞主流程
消息积压的处理	先扩容消费者并排查卡点，必要时转存后批量重投
定时任务的分片与防重	多实例部署时必须靠分布式锁或调度中心选主保证只跑一次
灰度发布	按用户/流量比例逐步放量，配合监控与快速回滚
链路追踪	全链路 traceId 透传，是分布式问题定位的基础设施
时间同步 NTP	时钟漂移会破坏以时间为依据的逻辑（超时、ID、租约），必须有 NTP
拆分与治理的边界	服务拆得越细，一致性、链路、排障成本越高——不要为了架构好看而拆

参考资料

Martin Kleppmann《数据密集型应用系统设计》（DDIA）
《分布式协议与算法实战》相关章节
Raft 论文：https://raft.github.io/
站点内《后端与分布式》相关笔记