一、CAP 定理1. 定义在一个分布式系统中以下三个特性最多只能同时满足两个特性含义CConsistency一致性所有节点在同一时刻看到的数据一致AAvailability可用性每个请求都能在合理时间内收到非错误响应PPartition tolerance分区容错性系统在网络分区发生时仍能继续运行2. 为什么必须选 P在真实分布式环境下网络分区不可避免因此 P 必须保留。实际选择只剩CP 系统保证一致性牺牲部分可用性。例ZooKeeper、HBaseAP 系统保证可用性允许短暂不一致。例Cassandra、DNS、DynamoDB3. 案例题考法通常不会直接问 CAP 定义而是给出分布式场景让你分析为什么该系统允许最终一致为什么该系统必须强一致某方案属于 CP 还是 AP二、BASE 理论1. 定义BASE 是 CAP 中 AP 思路的落地指导全称缩写含义说明BABasically Available基本可用允许部分功能降级或延迟但核心可用SSoft State软状态允许系统存在中间状态如数据同步中EEventually Consistent最终一致一段时间后所有副本数据趋于一致2. BASE vs ACID维度ACIDBASE一致性模型强一致最终一致关注点正确性可用性与吞吐适用场景传统关系型数据库事务分布式系统代表MySQL 事务NoSQL、消息队列三、分布式事务1. 为什么需要分布式事务当业务操作跨越多个服务或多个数据库时单机事务无法保证全局一致性。例如下单扣库存 扣余额 创建订单涉及三个服务。2. 常见方案2.1 两阶段提交2PC原理由一个协调者统一管理多个参与者的事务提交。阶段一准备阶段Prepare/Vote协调者向所有参与者发送准备提交请求各参与者执行事务操作但不提交写 undo/redo 日志各参与者回复同意或中止阶段二提交阶段Commit/Abort如果所有参与者都同意协调者发送提交所有参与者正式提交如果有任何一个参与者中止协调者发送回滚所有参与者回滚优点保证强一致性缺点同步阻塞参与者在等待协调者指令期间处于阻塞状态单点故障协调者故障可能导致参与者永久阻塞数据不一致风险网络异常时部分参与者可能提交、部分回滚2.2 三阶段提交3PC在 2PC 基础上增加了一个预提交PreCommit阶段并引入了超时机制CanCommit协调者询问是否可以执行PreCommit参与者预执行并锁定资源DoCommit正式提交改进点减少阻塞、引入超时自动决策。不足实现复杂仍无法完全避免不一致。2.3 TCCTry-Confirm-Cancel原理将每个分布式操作拆分为三个阶段阶段含义说明Try尝试预留资源如冻结库存、冻结金额Confirm确认正式提交扣除冻结的资源Cancel取消回滚释放冻结的资源优点无需数据库级锁业务层面控制并发性能好缺点每个业务都要写 Try/Confirm/Cancel 三套逻辑开发成本高需要保证 Confirm 和 Cancel 的幂等性适用场景高并发、对性能要求高的场景如支付、转账2.4 Saga原理将一个长事务拆分为多个本地事务每个本地事务有对应的补偿事务。正向执行时依次调用各本地事务若某步失败则逆序执行已完成步骤的补偿事务。两种实现方式编排式Choreography各服务通过事件驱动自行协调协调式Orchestration由一个中心协调器统一调度优点不需要分布式锁各步骤独立事务性能好缺点只保证最终一致性补偿逻辑可能复杂编排式难以追踪全局状态3. 分布式事务方案对比方案一致性性能实现复杂度适用场景2PC强一致差阻塞中传统数据库3PC强一致一般高理论居多TCC最终一致好高三套逻辑高并发业务Saga最终一致好中长流程业务四、分布式锁1. 为什么需要分布式锁当多个服务实例同时操作同一资源如更新订单状态时需要互斥机制来保证同一时刻只有一个实例能执行关键操作。2. 三种主流实现2.1 基于数据库的分布式锁实现方式在数据库中创建一张锁表通过插入记录抢锁操作完成后删除记录释放锁。也可用SELECT ... FOR UPDATE行锁实现。优点实现简单无需额外中间件数据持久化便于审计缺点数据库成为单点性能瓶颈若进程异常退出锁记录可能永久存在锁泄漏高并发下锁争用严重无原生过期机制2.2 基于 Redis 的分布式锁实现方式使用SET key value NX EX timeout命令NX仅当 key 不存在时设置成功互斥EX设置过期时间防死锁value设为随机唯一值释放时验证身份防误删释放锁用 Lua 脚本保证检查 value 删除 key的原子性。优点性能高、延迟低支持自动过期缺点主从切换时可能丢锁Master 挂掉锁未同步到 Slave需要处理续租问题业务执行时间超过过期时间实现需要注意原子性与幂等性Redlock 算法了解为解决单节点 Redis 锁的可靠性问题Redis 作者提出 Redlock向 N 个独立 Redis 节点请求锁获取 N/21 个以上才算成功。2.3 基于 ZooKeeper 的分布式锁实现方式利用 ZooKeeper 的临时顺序节点每个客户端在指定路径下创建临时顺序节点检查自己是否是序号最小的节点如果是获得锁否则监听前一个节点的删除事件前一个节点删除后再检查自己是否最小优点客户端断开连接临时节点自动删除天然防死锁顺序节点实现公平锁ZooKeeper 集群本身高可用缺点性能不如 Redis涉及 ZK 集群同步需要维护 ZooKeeper 集群实现相对复杂2.4 基于 Etcd 的分布式锁实现方式利用 Etcd 的租约Lease 前缀 事务机制。优点租约天然解决过期问题、强一致性Raft 协议。缺点相对小众生态不如 ZK/Redis。3. 分布式锁对比总结维度数据库RedisZooKeeperEtcd性能低高中中可靠性中单点中主从问题高高实现复杂度低中高高防死锁需自行处理过期机制临时节点租约机制公平性无无有顺序节点有五、负载均衡1. 定义将请求分发到多个服务器实例以提升系统吞吐量和可用性。2. 常见算法算法原理特点轮询Round Robin依次分配给每台服务器简单、公平不考虑服务器差异加权轮询按权重分配高性能机器分更多适应异构环境随机随机选一台简单大量请求下趋于均匀最少连接分配给当前连接数最少的服务器适合长连接场景IP 哈希对客户端 IP 取哈希决定分配保证同一客户端落到同一服务器一致性哈希哈希环 虚拟节点节点增减时只影响相邻数据3. 一致性哈希原理将哈希值空间组织成一个虚拟的环0 ~ 2^32-1将服务器节点映射到环上将数据的 Key 也映射到环上沿顺时针找到第一个服务器节点就是目标虚拟节点为避免数据倾斜将每个物理节点映射为多个虚拟节点均匀分布在环上。优点增减节点时只影响环上相邻区间的数据迁移影响范围小。适用场景分布式缓存、分布式存储的数据分片。六、服务治理1. 服务注册与发现组件说明服务注册中心维护所有服务实例的地址信息如 Nacos、Consul、Eureka、ZooKeeper服务注册服务启动时向注册中心登记自己的地址与元信息服务发现调用方从注册中心获取目标服务的地址列表健康检查注册中心定期探测服务实例是否存活2. 限流目的保护系统不被突发流量击垮。算法原理固定窗口计数器在固定时间窗口内计数超过阈值则拒绝滑动窗口计数器窗口随时间滑动统计更平滑漏桶Leaky Bucket请求进入桶中以固定速率流出令牌桶Token Bucket以固定速率生成令牌请求消耗令牌3. 熔断目的当下游服务不可用时快速失败避免级联故障。三种状态关闭Closed正常调用统计失败率打开Open达到阈值后直接返回错误不再调用下游半开Half-Open一段时间后试探性放入少量请求成功则关闭断路器4. 降级目的系统压力过大时主动放弃部分非核心功能保证核心功能可用。常见方式返回兜底数据如缓存中的旧数据关闭非核心功能简化业务流程5. 限流、熔断、降级的区别维度限流熔断降级保护对象保护自身保护自身不被下游拖垮保护核心功能触发条件流量超阈值下游失败率过高系统资源不足处理方式拒绝超出请求快速失败关闭非核心功能七、微服务拆分原则案例题如果涉及微服务设计可能会问拆分原则单一职责原则每个服务只做一件事业务边界清晰围绕业务能力拆分而非技术层高内聚低耦合服务内部紧密相关服务之间尽量独立数据自治每个服务拥有自己的数据库可独立部署服务升级不应要求其他服务同时升级适当粒度不要拆太细增加运维复杂度也不要太粗退化为单体八、答题模板分布式锁优缺点题基于 [X] 的分布式锁优点1. … 2. …缺点1. … 2. …适用场景…分布式事务对比题按以下维度逐项对比一致性级别、性能、实现复杂度、适用场景。微服务概念题微服务是一种架构风格将单体应用拆分为一组小型服务每个服务运行在独立进程中通过轻量级通信机制协作可独立部署。优点1. … 2. … 3. … 4. …挑战1. … 2. … 3. … 4. … 
长河君 · 2026/11/3 2:05:42 · 阅读 1.2k 分篇三：分布式系统设计
一、CAP 定理1. 定义在一个分布式系统中以下三个特性最多只能同时满足两个特性含义CConsistency一致性所有节点在同一时刻看到的数据一致AAvailability可用性每个请求都能在合理时间内收到非错误响应PPartition tolerance分区容错性系统在网络分区发生时仍能继续运行2. 为什么必须选 P在真实分布式环境下网络分区不可避免因此 P 必须保留。实际选择只剩CP 系统保证一致性牺牲部分可用性。例ZooKeeper、HBaseAP 系统保证可用性允许短暂不一致。例Cassandra、DNS、DynamoDB3. 案例题考法通常不会直接问 CAP 定义而是给出分布式场景让你分析为什么该系统允许最终一致为什么该系统必须强一致某方案属于 CP 还是 AP二、BASE 理论1. 定义BASE 是 CAP 中 AP 思路的落地指导全称缩写含义说明BABasically Available基本可用允许部分功能降级或延迟但核心可用SSoft State软状态允许系统存在中间状态如数据同步中EEventually Consistent最终一致一段时间后所有副本数据趋于一致2. BASE vs ACID维度ACIDBASE一致性模型强一致最终一致关注点正确性可用性与吞吐适用场景传统关系型数据库事务分布式系统代表MySQL 事务NoSQL、消息队列三、分布式事务1. 为什么需要分布式事务当业务操作跨越多个服务或多个数据库时单机事务无法保证全局一致性。例如下单扣库存 扣余额 创建订单涉及三个服务。2. 常见方案2.1 两阶段提交2PC原理由一个协调者统一管理多个参与者的事务提交。阶段一准备阶段Prepare/Vote协调者向所有参与者发送准备提交请求各参与者执行事务操作但不提交写 undo/redo 日志各参与者回复同意或中止阶段二提交阶段Commit/Abort如果所有参与者都同意协调者发送提交所有参与者正式提交如果有任何一个参与者中止协调者发送回滚所有参与者回滚优点保证强一致性缺点同步阻塞参与者在等待协调者指令期间处于阻塞状态单点故障协调者故障可能导致参与者永久阻塞数据不一致风险网络异常时部分参与者可能提交、部分回滚2.2 三阶段提交3PC在 2PC 基础上增加了一个预提交PreCommit阶段并引入了超时机制CanCommit协调者询问是否可以执行PreCommit参与者预执行并锁定资源DoCommit正式提交改进点减少阻塞、引入超时自动决策。不足实现复杂仍无法完全避免不一致。2.3 TCCTry-Confirm-Cancel原理将每个分布式操作拆分为三个阶段阶段含义说明Try尝试预留资源如冻结库存、冻结金额Confirm确认正式提交扣除冻结的资源Cancel取消回滚释放冻结的资源优点无需数据库级锁业务层面控制并发性能好缺点每个业务都要写 Try/Confirm/Cancel 三套逻辑开发成本高需要保证 Confirm 和 Cancel 的幂等性适用场景高并发、对性能要求高的场景如支付、转账2.4 Saga原理将一个长事务拆分为多个本地事务每个本地事务有对应的补偿事务。正向执行时依次调用各本地事务若某步失败则逆序执行已完成步骤的补偿事务。两种实现方式编排式Choreography各服务通过事件驱动自行协调协调式Orchestration由一个中心协调器统一调度优点不需要分布式锁各步骤独立事务性能好缺点只保证最终一致性补偿逻辑可能复杂编排式难以追踪全局状态3. 分布式事务方案对比方案一致性性能实现复杂度适用场景2PC强一致差阻塞中传统数据库3PC强一致一般高理论居多TCC最终一致好高三套逻辑高并发业务Saga最终一致好中长流程业务四、分布式锁1. 为什么需要分布式锁当多个服务实例同时操作同一资源如更新订单状态时需要互斥机制来保证同一时刻只有一个实例能执行关键操作。2. 三种主流实现2.1 基于数据库的分布式锁实现方式在数据库中创建一张锁表通过插入记录抢锁操作完成后删除记录释放锁。也可用SELECT ... FOR UPDATE行锁实现。优点实现简单无需额外中间件数据持久化便于审计缺点数据库成为单点性能瓶颈若进程异常退出锁记录可能永久存在锁泄漏高并发下锁争用严重无原生过期机制2.2 基于 Redis 的分布式锁实现方式使用SET key value NX EX timeout命令NX仅当 key 不存在时设置成功互斥EX设置过期时间防死锁value设为随机唯一值释放时验证身份防误删释放锁用 Lua 脚本保证检查 value 删除 key的原子性。优点性能高、延迟低支持自动过期缺点主从切换时可能丢锁Master 挂掉锁未同步到 Slave需要处理续租问题业务执行时间超过过期时间实现需要注意原子性与幂等性Redlock 算法了解为解决单节点 Redis 锁的可靠性问题Redis 作者提出 Redlock向 N 个独立 Redis 节点请求锁获取 N/21 个以上才算成功。2.3 基于 ZooKeeper 的分布式锁实现方式利用 ZooKeeper 的临时顺序节点每个客户端在指定路径下创建临时顺序节点检查自己是否是序号最小的节点如果是获得锁否则监听前一个节点的删除事件前一个节点删除后再检查自己是否最小优点客户端断开连接临时节点自动删除天然防死锁顺序节点实现公平锁ZooKeeper 集群本身高可用缺点性能不如 Redis涉及 ZK 集群同步需要维护 ZooKeeper 集群实现相对复杂2.4 基于 Etcd 的分布式锁实现方式利用 Etcd 的租约Lease 前缀 事务机制。优点租约天然解决过期问题、强一致性Raft 协议。缺点相对小众生态不如 ZK/Redis。3. 分布式锁对比总结维度数据库RedisZooKeeperEtcd性能低高中中可靠性中单点中主从问题高高实现复杂度低中高高防死锁需自行处理过期机制临时节点租约机制公平性无无有顺序节点有五、负载均衡1. 定义将请求分发到多个服务器实例以提升系统吞吐量和可用性。2. 常见算法算法原理特点轮询Round Robin依次分配给每台服务器简单、公平不考虑服务器差异加权轮询按权重分配高性能机器分更多适应异构环境随机随机选一台简单大量请求下趋于均匀最少连接分配给当前连接数最少的服务器适合长连接场景IP 哈希对客户端 IP 取哈希决定分配保证同一客户端落到同一服务器一致性哈希哈希环 虚拟节点节点增减时只影响相邻数据3. 一致性哈希原理将哈希值空间组织成一个虚拟的环0 ~ 2^32-1将服务器节点映射到环上将数据的 Key 也映射到环上沿顺时针找到第一个服务器节点就是目标虚拟节点为避免数据倾斜将每个物理节点映射为多个虚拟节点均匀分布在环上。优点增减节点时只影响环上相邻区间的数据迁移影响范围小。适用场景分布式缓存、分布式存储的数据分片。六、服务治理1. 服务注册与发现组件说明服务注册中心维护所有服务实例的地址信息如 Nacos、Consul、Eureka、ZooKeeper服务注册服务启动时向注册中心登记自己的地址与元信息服务发现调用方从注册中心获取目标服务的地址列表健康检查注册中心定期探测服务实例是否存活2. 限流目的保护系统不被突发流量击垮。算法原理固定窗口计数器在固定时间窗口内计数超过阈值则拒绝滑动窗口计数器窗口随时间滑动统计更平滑漏桶Leaky Bucket请求进入桶中以固定速率流出令牌桶Token Bucket以固定速率生成令牌请求消耗令牌3. 熔断目的当下游服务不可用时快速失败避免级联故障。三种状态关闭Closed正常调用统计失败率打开Open达到阈值后直接返回错误不再调用下游半开Half-Open一段时间后试探性放入少量请求成功则关闭断路器4. 降级目的系统压力过大时主动放弃部分非核心功能保证核心功能可用。常见方式返回兜底数据如缓存中的旧数据关闭非核心功能简化业务流程5. 限流、熔断、降级的区别维度限流熔断降级保护对象保护自身保护自身不被下游拖垮保护核心功能触发条件流量超阈值下游失败率过高系统资源不足处理方式拒绝超出请求快速失败关闭非核心功能七、微服务拆分原则案例题如果涉及微服务设计可能会问拆分原则单一职责原则每个服务只做一件事业务边界清晰围绕业务能力拆分而非技术层高内聚低耦合服务内部紧密相关服务之间尽量独立数据自治每个服务拥有自己的数据库可独立部署服务升级不应要求其他服务同时升级适当粒度不要拆太细增加运维复杂度也不要太粗退化为单体八、答题模板分布式锁优缺点题基于 [X] 的分布式锁优点1. … 2. …缺点1. … 2. …适用场景…分布式事务对比题按以下维度逐项对比一致性级别、性能、实现复杂度、适用场景。微服务概念题微服务是一种架构风格将单体应用拆分为一组小型服务每个服务运行在独立进程中通过轻量级通信机制协作可独立部署。优点1. … 2. … 3. … 4. …挑战1. … 2. … 3. … 4. …