vault backup: 2026-08-09 19:06:40

05.架构/service-governance/服务注册与发现_test.md

@@ -0,0 +1,146 @@
+---
+tags: [test/review, architecture, arch/microservice, service-discovery]
+create time: 2026-08-09 12:00
+---
+
+# 服务注册与发现 — 测试题
+
+## 概述
+本测试覆盖服务注册/注销/续约流程、Eureka/AP 取向、Nacos CP/AP 可切换、Consul 特性以及 CAP 理论在注册中心中的体现。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+服务注册的标准三步走流程是：
+
+A. 注册 → 查询 → 注销
+B. 注册 → 续约（心跳）→ 注销
+C. 发现 → 健康检查 → 更新
+D. 心跳 → 续约 → 下线
+
+### Q2（基础）→ 
+
+Eureka 的自我保护机制在什么条件下会被触发？
+
+A. 15 分钟内超过 50% 实例未发送心跳
+B. 15 分钟内超过 85% 实例未发送心跳
+C. 所有实例同时宕机
+D. 注册中心 CPU 使用率超过 90%
+
+### Q3（进阶）— 核心原理
+
+Nacos 在同一套代码中为什么能既支持 AP 又支持 CP 模式？
+
+A. 通过动态切换一致性协议实现，运行时修改配置即可
+B. 两种模式使用不同的数据存储路径和服务类型
+C. Nacos 有两个独立的二进制进程分别处理 AP 和 CP
+D. 基于 K8s Namespace 做逻辑隔离
+
+### Q4（进阶）— 比较/辨析
+
+Consul 的三个独特优势不包括以下哪一项？
+
+A. Serf Gossip 协议的成员管理
+B. 丰富的健康检查方式（TCP/HTTP/script/Docker/TTL）
+C. 内嵌 Raft 一致性的 KV 存储
+D. 原生支持多级缓存（本地 + 远程）
+
+### Q5（深入）— 场景推理
+
+某金融系统对数据一致性要求极高，在选型服务注册中心时最应该考虑哪个因素？
+
+A. 需要高可用容忍短暂不一致 → 选 Eureka
+B. 需要强一致性 → 选 Nacos CP 模式或 Consul TCP 接口
+C. DNS 接口最快 → 选 Consul DNS
+D. 客户端缓存最可靠 → 选 Eureka 并关闭自我保护
+
+### Q6（深入）— 源码级/边界场景
+
+PACELC 理论对 CAP 做了哪些补充？
+
+A. PACELC 指出无分区时也需权衡延迟与一致性
+B. PACELC 指出分区恢复后需先进行数据同步再服务
+C. PACELC 引入了第三维度——性能，CAP 只有两个维度
+D. PACELC 证明 CAP 定理在分布式系统中是错误的
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+Eureka 的消费者会**缓存**服务列表，默认每 _____ 秒刷新一次。这样即使注册中心完全不可用，消费方依然能根据本地缓存继续通信。
+
+> **提示**: 回顾原文 Eureka 小节中关于客户端缓存的描述。
+
+### F2 — 填空2
+
+Consul 的 DNS 接口因为是 _____ 模式的——直接指向随机节点读取本地内存缓存，不经过 Raft 日志——所以速度极快但可能读到旧数据。
+
+> **提示**: 回想 CAP/PACELC 表格中 Consul DNS 的行。
+
+### F3 — 填空3
+
+Nacos 通过 _____ 实现环境隔离（dev/test/prod），每个命名空间有独立的服务和配置视图。底层基于 PostgreSQL 存储元数据。
+
+> **提示**: Nacos 的环境隔离术语来自 Kubernetes。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+面试官问你："Eureka 的自我保护机制在生产环境中什么时候该关？"请给出你的完整回答，包括：
+- 自我保护机制的作用是什么
+- 关了会有什么风险
+- 什么场景下可以关
+- 如果不关应该如何监控
+
+> **答题框架提示**:
+> 1. 解释机制的原理和风险
+> 2. 分场景讨论
+> 3. 给出具体的监控建议
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | B | 标准三步：① 注册服务（POST /register）；② 心跳续约（维持 lastDirtyTimestamp）；③ 主动注销（DELETE /deregister）。故障场景下感知延迟通常为续约超时周期（30~90 秒）。 |
+| Q2 | B | 15 分钟内超过 85% 实例未发心跳触发保护窗口锁定，不再剔除任何实例。宁可多调几次失败也不主动剔。 |
+| Q3 | B | 不同模式使用不同的存储路径和服务类型：CP 用 `nacos.v1.auth.user`（Raft），AP 用 `nacos.v1.instance`（Distro）。不是运行时切换而是物理隔离的路径。 |
+| Q4 | D | Consul 的优势是 Serf Gossip、丰富健康检查、KV 存储。多级缓存不是 Consul 的功能，那是 Redis/Caffeine 层的职责。 |
+| Q5 | B | 金融系统需要强一致性，应选 Nacos CP 模式（Raft）或 Consul TCP 接口（Raft Leader）。Eureka 最终一致不适合。DNS 可能 stale。关闭自我保护会增加雪崩风险。 |
+| Q6 | A | PACELC = PA（Partition tolerant, choose Availability）+ EC（Else, choose Between Consistency and Latency）。CAP 只讨论分区场景，PACELC 补充了无分区时的 L/C 权衡。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `30` | 消费者每 30 秒刷新一次本地缓存。结合 Eureka 的续约超时周期（通常 30~90 秒），故障检测延迟约在一个续约周期左右。 |
+| F2 | `AP` | Consul DNS API 直接读取随机节点的本地内存缓存，不走 Raft 日志，因此速度快但读到的可能是 stale data。如果需要强一致则走 TCP 端口。 |
+| F3 | `namespace` | Nacos 的 namespace 相当于 K8s 的 Namespace，实现 dev/test/prod 的物理隔离。每个 namespace 独立存储服务列表和配置数据。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **机制作用**：自我保护防止因网络抖动大量实例被误判为宕机而批量剔除，避免雪崩式下线。
+2. **关了的风险**：一旦关闭，心跳稍微延迟就会被剔除，一批实例被认为故障全部移除，调用方拿不到任何健康实例。
+3. **适用场景**：金融类对一致性要求高的场景可以考虑关闭；普通互联网业务不建议关，误判的危害大于不调用的危害。
+4. **监控建议**：生产环境必须监控 `eureka.server.selfPreservationThreshold` 指标，当该阈值被触发时告警通知运维介入检查。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[负载均衡算法]]
+- [[限流熔断降级]]
+- [[配置中心设计]]

05.架构/service-governance/负载均衡算法_test.md

@@ -0,0 +1,142 @@
+---
+tags: [test/review, architecture, arch/microservice, load-balancing]
+create time: 2026-08-09 12:00
+---
+
+# 负载均衡算法 — 测试题
+
+## 概述
+本测试覆盖客户端 vs 服务端负载均衡架构、轮询/随机/一致性哈希/最少连接等核心算法、Spring Cloud LoadBalancer 实现原理以及加权轮询的工程实现。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+以下关于客户端负载均衡与服务端负载均衡的说法中，正确的是：
+
+A. 客户端负载均衡延迟更高，因为多了一次网络跳
+B. 服务端负载均衡的故障隔离更好——LB 单点故障不影响其他调用
+C. 客户端负载均衡需要为每种语言实现 SDK，服务端 LB 协议无关
+D. Nginx 是客户端负载均衡的典型代表
+
+### Q2（基础）→ 
+
+以下哪种负载均衡算法最适合 WebSocket 长连接场景？
+
+A. 简单轮询（Round Robin）
+B. 随机法
+C. 最少连接数（Least Connections）
+D. 一致性哈希
+
+### Q3（进阶）— 核心原理
+
+传统哈希 `hash(instance) % n` 在实例增减时为什么会导致大量请求重新路由？
+
+A. 因为 hash 函数的不均匀性
+B. 因为 n 变化后所有 hash 结果对新的 n 取模都变了
+C. 因为虚拟节点数量不足
+D. 因为 MurmurHash 本身不适合负载均衡
+
+### Q4（进阶）— 比较/辨析
+
+一致性哈希中虚拟节点的主要作用是什么？
+
+A. 提高 hash 值的随机性
+B. 解决数据倾斜问题，使物理实例在环上分布更均匀
+C. 增加系统容错能力，某节点挂了可以立即接替
+D. 减少 hash 冲突的概率
+
+### Q5（深入）— 场景推理
+
+一个微服务有 5 个实例，权重分别为 A=5、B=3、C=2、D=1、E=1（总权重 12）。使用平滑加权轮询算法，第一个被选中的实例一定是：
+
+A. B（权重 3）
+B. C（权重 2）
+C. A（权重 5）
+D. 无法确定，取决于初始 current_weight
+
+### Q6（深入）— 源码级/边界场景
+
+关于 Spring Cloud LoadBalancer，以下说法哪个是正确的？
+
+A. 它内置了重试和熔断能力
+B. 基于 Reactor 响应式编程，返回 Flux<ServiceInstance>
+C. 默认使用一致性哈希算法
+D. 只支持 HTTP 协议的实例选择
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+一致性哈希将 hash 值空间映射到环上（0 ~ _____），服务和请求都 hash 到环上的同一点，请求顺时针找到最近的实例。移除一个实例只影响其相邻的两个虚拟节点范围，而非全部数据。
+
+> **提示**: 回忆原文中提到的一致性哈希环的范围上限。
+
+### F2 — 填空2
+
+一致性哈希中，每个物理实例对应的虚拟节点数 k 通常取 _____~_____。如果实例频繁增删（每几分钟变一次），k 要调得更大（500+）才能维持稳定性，但会增加内存开销。
+
+> **提示**: 原文中有一个具体的数值范围。
+
+### F3 — 填空3
+
+Nginx 的 smooth weighted round robin 算法中，每次选出 current_weight 最大的实例后，执行 `selected.CurWeight -= _____`，保证长期均衡。
+
+> **提示**: 减去的应该是总权重，这样每个实例的 CurWeight 会在一个周期内回到初始状态。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+某电商大促场景中，你有 10 个商品推荐服务实例，其中 3 台是高性能机器（容量大），7 台是普通机器（容量小）。流量高峰时要求充分利用高性能机器的资源。请说明你会选用哪种负载均衡算法，如何配置参数，并解释为什么不用简单轮询或随机法。
+
+> **答题框架提示**:
+> 1. 分析场景的核心矛盾（规格差异）
+> 2. 推荐算法并说明理由
+> 3. 给出具体配置思路
+> 4. 讨论边界情况
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | C | A 错：客户端 LB 少一次网络跳所以延迟低；B 错：LB 单点故障影响全部请求，故障隔离差；D 错：Nginx 是服务端 LB。只有 C 正确——客户端 LB 需要各语言的 SDK（如 Spring Cloud LoadBalancer for Java）。 |
+| Q2 | C | WebSocket 长连接场景下不同连接的持续时间差异大，最少连接数能保证新请求发给当前活跃连接最少的实例，避免某个实例堆积大量长连接而其他实例闲置。 |
+| Q3 | B | 当实例数从 n 变为 n±1 时，几乎所有 key 的 hash(key) % new_n 都会不同于原来的结果，导致约 (n-1)/n 的数据需要迁移。这就是一致性哈希要解决的问题。 |
+| Q4 | B | 如果不使用虚拟节点，少数几个物理实例在环上的分布会很不均匀，造成严重的数据倾斜。K=100~200 个虚拟节点让分布趋近均匀。 |
+| Q5 | C | 平滑加权轮询第一轮时所有实例的 CurWeight = 0，加上各自 Weight 后 A 的 CurWeight = 5 最大，所以第一轮一定选 A。之后 A 减 12 变为 -7，其他依次加完再选。 |
+| Q6 | B | Spring Cloud LoadBalancer 基于 Reactor，返回 Flux<ServiceInstance>。它**不提供**重试和熔断（那是 Resilience4j 的职责），默认策略是 RoundRobinLocator（轮询），不是哈希。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `2^32`（或"4294967296"） | 一致性哈希将 32 位 hash 空间映射为环形地址空间，首尾相接。顺时针寻找最近实例的逻辑确保了实例增减时的最小影响范围。 |
+| F2 | `100`；`200` | 这是业界经验值。太少了分布不均，太多了内存占用大且维护代价高。频繁增删场景需要 500+ 的虚拟节点数。 |
+| F3 | `totalW`（或"总权重 total_weight"） | Nginx 的平滑加权轮询核心公式：cur += weight（累积），选 max 后 selected -= total。这样经过一个完整周期，每个实例被选中的次数恰好等于它的权重占比。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **核心矛盾**：性能差异大的实例不能用简单轮询——每台都会被分到相同数量的请求，导致弱机过载而强机资源浪费。
+2. **推荐算法**：加权轮询（Weighted Round Robin）。将 3 台高性能机的权重设为普通机的若干倍（如 3:1 或根据实测 QPS 计算比例），使得长期来看请求按容量比例分配。
+3. **不选简单的理由**：简单轮询无视容量差异；随机法在小样本下可能极端不均（连续命中同一个弱机），大促场景不能接受这种不确定性。
+4. **边界处理**：需要考虑实例下线时的权重动态调整（Hot Restart 机制）、健康检查剔除故障实例后的自动重新加权。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[服务注册与发现]]
+- [[限流熔断降级]]

05.架构/service-governance/配置中心设计_test.md

@@ -0,0 +1,144 @@
+---
+tags: [test/review, architecture, arch/microservice, config-center]
+create time: 2026-08-09 12:00
+---
+
+# 配置中心设计 — 测试题
+
+## 概述
+本测试覆盖 Apollo 三级 Namespace 模型、Nacos Config 长轮询推送机制、配置热更新实现原理、版本管理和回滚策略。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+Apollo 的配置模型中，以下哪一层不是三级结构的一部分？
+
+A. Environment（部署环境：dev/test/prod）
+B. Application（业务应用）
+C. Namespace（配置类型）
+D. Tenant（租户）
+
+### Q2（基础）→ 
+
+Nacos Config 的秒级推送底层使用什么机制？
+
+A. WebSocket 长连接
+B. HTTP 长轮询（Long Polling）
+C. MQTT 发布/订阅
+D. Redis Pub/Sub
+
+### Q3（进阶）— 核心原理
+
+Nacos Config 长轮询的工作原理是什么？
+
+A. 客户端每 5 秒定时发送请求，服务端每次都立即返回
+B. 客户端发起请求后服务端将其挂起在 waitList 中，配置变化时写入 notificationId 后返回；如果 30 秒无变更则超时返回
+C. 服务端主动通过 WebSocket 向客户端推送变更通知
+D. 客户端通过 Redis Pub/Sub 订阅配置变更事件
+
+### Q4（进阶）— 比较/辨析
+
+以下关于 Apollo 和 Nacos Config 的区别描述中，哪个是正确的？
+
+A. Apollo 用长轮询，Nacos 用短轮询
+B. Apollo 的 namespace 支持更细粒度的权限控制和审批流，ConfigMap 只支持键值对映射
+C. Nacos 不支持灰度发布，只有全量发布
+D. Apollo 不支持多环境隔离，需要手动管理
+
+### Q5（深入）— 场景推理
+
+某团队在生产环境中修改了数据库连接串配置，服务重启后出现大量连接失败。从配置中心的角度看，最根本的原因是什么？
+
+A. 使用了长轮询而非 WebSocket
+B. 配置变更没有经过审核+灰度流程，直接全量推送到生产环境
+C. Nacos 的 namespace 粒度不够细
+D. Apollo 的三级结构过于复杂
+
+### Q6（深入）— 源码级/边界场景
+
+Apollo 的回滚操作本质上是怎样的？
+
+A. 将版本号倒退回上一个版本，删除中间版本的所有记录
+B. 用当前最新状态 + 差异计算生成一个新版本，保证发布记录单调递增
+C. 复制上一个版本的快照作为新版本，不产生新的变更记录
+D. 在数据库中将对应行的 version 字段减 1
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+Apollo 客户端发现配置新版本的默认拉取周期是 _____ 秒。当服务端生成了新的 releaseKey 后，客户端在下一次拉取时发现版本变化即触发热加载。
+
+> **提示**: 回想原文中 Apollo 灰度发布流程的描述。
+
+### F2 — 填空2
+
+Spring Cloud 中使用 `@RefreshScope` 注解的 Bean 在配置变更后会自动生成_____，使得下次调用 getter 时获取的是最新的配置值。
+
+> **提示**: 这个代理技术是 Spring 框架的核心特性之一，基于 AOP 实现。
+
+### F3 — 填空3
+
+配置热更新最大的风险是配置变更导致服务行为突变。Apollo 的解决方案是"_____+灰度"，先让少量实例生效观察指标，再逐步全量。
+
+> **提示**: 两个字的动词，表示一个审核的动作。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+面试官问："为什么 Nacos Config 用长轮询而不是 WebSocket？"请给出你的完整回答，并扩展到以下讨论：
+- 长轮询 vs WebSocket 各自的优缺点
+- 微服务架构中的中间件链路限制
+- 在什么场景下可能考虑 WebSocket
+
+> **答题框架提示**:
+> 1. 长轮询的核心优势
+> 2. Websocket 的主要劣势（在微服务语境下）
+> 3. 混合方案的思考
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | D | Apollo 的三级结构是 Environment → Application → Cluster → Namespace。Tenant（租户）不是 Apollo 的标准层级——那是多租户 SaaS 平台的概念。 |
+| Q2 | B | Nacos Config 使用 HTTP 长轮询实现秒级推送。不是 WebSocket（因为要兼容所有 HTTP 中间件），也不是 MQTT 或 Redis Pub/Sub。 |
+| Q3 | B | 长轮询核心：客户端请求挂起到 waitList，配置变化时写 notificationId 后立即返回；30 秒超时防止连接无限期挂起。客户端收到通知后再拉取最新配置。 |
+| Q4 | B | A 错：两者都用长轮询；C 错：Nacos 也支持灰度发布和回滚；D 错：Apollo 天然支持多环境隔离（namespace 就是为这个设计的）。 |
+| Q5 | B | 直接全量推送错误配置是最危险的——所有实例同时失效。正确做法是先审核进入待发布状态，灰度到少数 IP 验证无误后再全量。 |
+| Q6 | B | 回滚的本质不是"倒退版本"而是用当前状态 + 差异生成新版本。这样保证了发布记录永远单调递增（版本号一直增长），不会产生环形依赖。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `5` | Apollo Client 每 5 秒轮询一次服务端检查是否有新 releaseKey。这是配置热更新的延迟上限（理想情况下一个拉取周期即可感知变更）。 |
+| F2 | `代理 Bean` | @RefreshScope 会动态创建代理对象，每次 getter 调用时检查缓存是否过期，若已过期则从配置中心拉取最新值。 |
+| F3 | `审核` | "审核+灰度"流程：编辑配置进入审核状态→审核通过发布→灰度规则指定特定 IP 先接收→验证后全量发布。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **长轮询的核心优势**：兼容所有 HTTP 中间件（网关、CDN、负载均衡器）。微服务架构中请求路径上通常有 Spring Cloud Gateway 等 HTTP-only 代理，这些代理不会做 WebSocket 升级，导致连接断开。
+2. **WebSocket 的劣势**：全链路需要升级支持，跨 NAT/防火墙困难；运维复杂度显著增加。
+3. **各自的缺点**：长轮询的连接保持期间占用服务端内存；WebSocket 需要维护连接池和心跳保活。
+4. **WS 的适用场景**：需要毫秒级推送且能控制全链路的内部系统（如实时协作编辑器、游戏服务器）。对外暴露的微服务配置同步场景不适合。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[服务注册与发现]]
+- [[限流熔断降级]]

05.架构/service-governance/限流熔断降级_test.md

@@ -0,0 +1,143 @@
+---
+tags: [test/review, architecture, arch/microservice, rate-limiting]
+create time: 2026-08-09 12:00
+---
+
+# 限流熔断降级 — 测试题
+
+## 概述
+本测试覆盖三种限流算法（滑动窗口、令牌桶、漏桶）、熔断三态转换机制、Sentinel 与 Resilience4j 核心特性以及降级兜底策略。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+以下哪种限流算法**不允许突发流量**，强制输出匀速？
+
+A. 计数器限流
+B. 令牌桶算法
+C. 漏桶算法
+D. 以上都不对
+
+### Q2（基础）→ 
+
+熔断器从 Closed 状态转换到 Open 状态的典型触发条件是什么？
+
+A. 单个请求失败
+B. 最近 N 秒内成功率为零
+C. 失败率超过阈值（如 >50%）
+D. HPA 检测到 CPU 使用率过高
+
+### Q3（进阶）— 核心原理
+
+熔断半开（HalfOpen）状态的主要作用是什么？
+
+A. 降低服务器负载，减少请求量
+B. 用少量探测请求验证下游是否已恢复，避免直接进入 Closed 后流量暴增导致二次雪崩
+C. 为客户端提供缓冲时间，等待前端超时
+D. 在 Open 和 Closed 之间做数据同步
+
+### Q4（进阶）— 比较/辨析
+
+Resilience4j 与 Hystrix 的核心区别不包括以下哪项？
+
+A. Resilience4j 基于信号量隔离（轻），Hystrix 基于线程池隔离（重）
+B. Resilience4j 采用函数式设计，Hystrix 需要继承 Thread
+C. Resilience4j 不依赖 Spring Cloud，可以独立使用
+D. Resilience4j 不支持熔断功能
+
+### Q5（深入）— 场景推理
+
+某 API 网关需要对用户接口做限流保护。业务要求允许合理的突发流量（如用户刷新页面同时发多个请求），但限制长期平均速率。以下选型最合理的是：
+
+A. 漏桶——因为保护消费者不被打爆
+B. 令牌桶——因为允许突发消费存量令牌
+C. 固定窗口计数器——因为实现最简单
+D. 并发线程数限流——因为实现最轻量
+
+### Q6（深入）— 源码级/边界场景
+
+Sentinel 的滑动窗口与传统固定窗口的核心区别是什么？
+
+A. Sentinel 使用 Redis 做分布式计数，传统方式用本地内存
+B. Sentinel 将窗口细分为更小的 tick，在每个 tick 内独立计数再聚合；固定窗口在边界处会漏算（上一个窗口的尾巴 + 下一个窗口的头同时超限）
+C. Sentinel 支持更多算法（令牌桶+漏桶+计数器），传统方式只支持计数器
+D. Sentinel 不需要配置阈值，通过自适应学习自动设定
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+HPA（Horizontal Pod Autoscaler）的计算公式是：`targetReplicas = ceil(currentReplicas * (currentMetricValue / _____))`。例如当前 5 个副本，CPU 目标 70%，当前平均 CPU 使用率 91%，则扩容到 `ceil(5 * 91 / 70) = _____` 个副本。
+
+> **提示**: 第一个空填公式中的占位符名，第二个空填计算结果。
+
+### F2 — 填空2
+
+Prometheus 采集指标使用 Pull 模式而非 Push 模式的原因是：Pull 模式下失联的服务会自动被忽略（不再收到数据即标记为 down），而 Push 模式下挂了的服务停止发送数据但采集器不知道它们已经不存在了。请写出 Prometheus 中四种核心指标类型中的两种：_____、_____。
+
+> **提示**: 任选两种即可——Counter/Gauge/Histogram/Summary。
+
+### F3 — 填空3
+
+Token Bucket 和 Leaky Bucket 的选型建议：**对外暴露 API 时用_____**（允许客户端合理突发）；**内部服务间调用时用_____**（保护消费方不被打爆）。
+
+> **提示**: 每个空填一种算法名称。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+面试官问："为什么熔断要从 Open 到 HalfOpen 而不是直接从 Open 回到 Closed？"请详细解释原因，并结合以下场景说明后果：某个下游微服务的数据库连接池被打满，故障正在恢复中。
+
+> **答题框架提示**:
+> 1. HalfOpen 的安全阀作用
+> 2. 直接回 Closed 的后果分析
+> 3. HalfOpen 探测的具体流程
+> 4. 补充：如果 HalfOpen 也失败的策略
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | C | 漏桶的核心就是无论输入多猛，输出永远匀速——请求进入桶中排队处理，满了就溢出拒绝。令牌桶允许突发（桶满时可以一次性消耗多个令牌），计数器有窗口边界问题。 |
+| Q2 | C | 典型触发条件是失败率超过阈值（如最近 N 秒内失败率 > 50%）。单个请求失败不够成熔断，全为零太极端。 |
+| Q3 | B | HalfOpen 是一个安全阀：下游还在恢复时，直接进入 Closed 会让全部流量瞬间灌入，可能导致二次雪崩。有限的探测请求（通常 1~3 个）先验证下游是否真恢复了。 |
+| Q4 | D | D 是错误的——Resilience4j **完全支持**熔断功能。它的优势在于函数式 API 和装饰器模式。其他三项都是正确的区别点。 |
+| Q5 | B | 令牌桶适合保护生产者：允许突发流量（桶满时可突发消费存量令牌），但长期受限于平均速率。这正是对外 API 网关的需求特征。 |
+| Q6 | B | 固定窗口的问题在于边界效应：上一个窗口末尾 0.9 秒的请求和下一个窗口开头 0.9 秒的请求各占各自窗口但不超出阈值，合在一起可能翻倍。Sentinel 将窗口细分为更小的 tick 来消除这个问题。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `desiredMetricValue`；`7` | ceil(5 × 91 / 70) = ceil(6.5) = 7。HPA 不是实时的——依赖 metrics-server 每 15~60 秒采样，扩容有分钟级延迟。 |
+| F2 | `Counter`、`Gauge`（或 Histogram、Summary 任意两种） | Counter = 单调递增（如总请求数）；Gauge = 可上可下（如活跃连接数）；Histogram = 分桶统计（延迟分布）；Summary = 客户端计算分位数（P50/P99）。 |
+| F3 | `令牌桶`；`漏桶` | 对外 API 允许合理突发 → 令牌桶；内部服务间保护消费方 → 漏桶匀速处理。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **安全阀作用**：HalfOpen 是 Open 和 Closed 之间的缓冲层，用有限的探针先测试下游恢复情况。
+2. **直接回 Closed 的后果**：假设下游 DB 连接池被打满（比如只剩 5 个可用），如果直接从 Open 回 Closed，大量积压请求瞬间涌入会立即再次打满连接池，引发二次雪崩。
+3. **HalfOpen 流程**：仅发出 1~3 个探测请求给下游，只有全成功才转入 Closed。任一失败立刻重新进入 Open 并重置倒计时。探测期间原有业务请求仍被拦截。
+4. **补充**：如果连续多次 HalfOpen 都失败，可以引入渐进式加大探测流量的策略，或者人工介入告警。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[服务注册与发现]]
+- [[负载均衡算法]]
+- [[配置中心设计]]