第 35 章 微服务架构与治理

拆分把进程内约 100 ns 的调用换成了同机房 0.1~0.5 ms 的网络调用；本章所有治理手段，都是在替这笔三个数量级的账还债。

学习目标

读完本章，你应当能够：

1. 用团队规模、部署冲突频率、瓶颈独立性三个可观测判据判断拆分时机，给出微服务与单体的双向论证与"过早拆分"的反例；
2. 画出客户端发现与服务端发现两条路径，说明注册中心 AP/CP 取舍、健康检查的两类误判与 Eureka 自我保护的触发条件；
3. 列出七种负载均衡策略的判据，用算例证明最少连接数为什么常优于轮询，说清四层与七层的差异，并画出熔断器三态迁移图、给出六组参数的语义；
4. 辨析熔断与限流、Sentinel 与 Hystrix、线程池隔离与信号量隔离、幂等与并发控制，算出重试放大倍数，并设计从 TraceID 传播、采样到日志聚合的可观测链与跨服务排障流程。

前置知识检查

35.1 微服务与单体的取舍

35.1.1 双向论证：收益在组织层，代价在运行层

量化：进程内调用约 100 ns，同机房网络往返（RTT）约 0.1_{0.5 ms，相差 10³}10⁴ 倍，还额外承担序列化与"对端可能不响应"的不确定性；可用性按乘法衰减，5 个可用性 99.99% 的服务串联后约 0.9999⁵ ≈ 99.95%，年停机从约 53 分钟涨到约 4.4 小时。

35.1.2 拆分时机：三个可观测判据

1. 团队规模：同一代码库上并行开发超过约 8~10 人（两个披萨团队量级）时，评审、合并、发版排期的协调成本超过开发成本本身，此时按业务能力（business capability）切出端到端拥有制的服务；
2. 部署冲突频率：统计"我改了 A 模块却与 B 模块互相阻塞发布、必须一起回归"的次数，高到需要排队发版就是硬信号；
3. 瓶颈独立性：只有订单导出需要 10 倍机器、其余模块负载平稳，拆出去单独扩容的收益可量化；若所有模块负载同步涨落，拆了只是把进程边界搬了个家。

过早拆分的反例：3 人维护 2 万行 CRUD，按技术分层拆成 12 个服务。本地启动要拉起 12 个进程，改一个字段提交 5 个仓库，一次联调的时间超过写代码的时间，而"独立部署"收益为零（只有一个团队、一条流水线）；原本本地事务能保证的一致性，现在必须用分布式事务或补偿实现——把可控的复杂度换成了不可控的复杂度。

35.1.3 模块化单体作为中间态

模块化单体（modular monolith）= 单进程部署 + 单一数据库 + 编译期强制的模块边界：用 Maven/Gradle 子模块或包可见性隔离，跨模块只走显式接口；用架构守护测试（如 ArchUnit 规则）在 CI 中禁止订单模块直连库存模块的内部 DAO；模块间只传 DTO，不共享实体（entity）。价值是边界能低成本反复试错：拆错了回退只是重构包结构，而不是撤销一批线上服务。演进时务必不共享数据库，否则耦合只是从代码搬到了表上。

35.2 服务注册与发现

35.2.1 客户端发现与服务端发现

1
2
3
4

客户端发现（Eureka + Ribbon）：调用方拉取/订阅实例列表 → 自己按 LB 策略选实例 → 直连调用（少一跳，每种语言一套 SDK）
服务端发现（Kubernetes Service + kube-proxy/Ingress）：调用方只访问虚拟地址 orders.svc:8080
   → 节点内核按 iptables/IPVS 规则 DNAT 到真实 Pod（Endpoints 由 apiserver 维护，客户端零改造）
   代价是多一跳或一次 DNAT，虚拟 IP 让抓包与可观测性变差

35.2.2 注册中心的 AP 与 CP 取舍

取舍的本质是分区时更怕哪一种错误：AP 的风险是流量打到已死实例（可用性问题，由客户端重试与熔断兜底）；CP 的风险是注册中心整体拒绝服务，客户端连一份可用列表都拿不到（可用性直接归零）。所以服务发现偏 AP，选主与分布式锁必须 CP，不存在"又快又一致"的选项（Nacos 用临时/持久实例来分别对应这两种语义）。

35.2.3 健康检查的两种方式与各自的误判

Kubernetes 把主动探测分成三种：livenessProbe 失败重启容器（死锁类不可自愈故障）；readinessProbe 失败从 Endpoints 摘除但不重启（依赖暂时不可用、预热中）；startupProbe 在成功前不执行 liveness 检查，避免"启动慢 → 被判死 → 循环重启”。下线必须走优雅停机：先注销 → 等待一个不小于调用方列表缓存刷新时间的窗口 → 处理完在途请求 → 关闭；顺序颠倒就会必现"实例已销毁、调用方还在发请求"的错误。

衡量摘除策略只有一个锚点：摘除延迟 × 流量 = 打到坏实例上的错误请求数。注册中心注销慢、调用方列表缓存久、连接池里还有旧连接，任一处变慢都会直接体现为用户可见的错误率。

35.2.4 Eureka 的自我保护：保留过期实例是有意设计

Eureka 服务器每分钟比较"本应收到的续约数”（阈值 = 注册实例数 × 每分钟续约次数 × 0.85，renewalPercentThreshold 默认 0.85）与上一分钟实际收到的续约数；实际值低于阈值的 0.85 倍时触发自我保护：不再剔除任何过期实例，只记录告警。原因是分区时 Eureka 无法区分“客户端进程死了"与"客户端网络断了”：若按 TTL 大批剔除，客户端在恢复前拿到的列表会迅速变空，服务端发现模式下调用方直接判定"无可用实例”，全站失败。保留过期实例的代价是部分请求打到确实已死的实例，由客户端的连接超时、重试与熔断兜底——用少量请求失败换整体可用。

35.3 负载均衡策略与四七层差异

35.3.1 七种策略与判据

选型判据：实例同构用轮询/随机；预知异构用加权轮询；负载漂移且请求耗时长用最少连接；需要会话或本地缓存亲和用一致性哈希。

35.3.2 “最少连接"为什么常优于轮询

1
2
3
4
5
6

三台单核实例：A 单请求 2 ms（约 500 QPS），B、C 单请求 20 ms（各约 50 QPS）；入口 450 QPS
轮询（各 150 QPS）：A 用掉 0.30 s CPU/秒（30%，大量空闲）；B、C 各 3.00 s CPU/秒（300%，远超单核）
                    → 队列无界增长 → 响应变慢 → 上游超时 → 触发重试 → 流量再放大（见 35.5.2）
最少连接（稳态）：B、C 各被压在 50 QPS（满负荷）；A 承担剩余 350 QPS（低于其 500 能力）→ 有稳定工作点
机制：在途请求数天然反映实例快慢，流量被自动抽走；推广：轮询的总利用率由最慢实例决定（ρ = λ/(3 × μ_min)），
      最少连接使各实例在途数趋同，等价于按服务率分配到达率，总容量接近 Σμᵢ

不要把它说成万能：收敛需要时间（慢实例要先堆积出差异），请求耗时极短且均匀时与轮询无差别；当所有实例因共同依赖（如数据库）同时变慢时它也无能为力，那属于熔断与限流的职责。

35.3.3 四层与七层：不止是"快慢"的区别

追问两例：后端要拿真实客户端 IP，需 DR 模式加 toa 或 proxy_protocol；TLS 在网关终止后，后端只能靠 X-Forwarded-Proto 判断原始协议，且必须只信任网关写入的值。

35.3.4 LVS/Nginx/Envoy 的定位

LVS（内核四层，DR/TUN/NAT 模式，DR 只改 MAC、回包不经过转发器）是入口抗量的第一层，百万级连接只做转发；Nginx 是用户态七层反向代理（另有 stream 模块做四层），擅长路径分流、限流、静态缓存，配置以文件为单位重载；Envoy 是用户态七层代理，配置通过 xDS 动态下发且原生支持熔断、重试预算、追踪上报，所以成为服务网格的数据面（sidecar）。典型串接是 DNS/Anycast → LVS（四层抗量）→ 网关（七层路由与治理）→ 实例/sidecar：越往上能力越强、可承载的并发量级越低，因此是分工而非替代关系。

35.4 熔断器

35.4.1 三态与迁移条件

1
2
3
4
5
6
7
8
9

                窗口请求数 ≥ 最小样本数 且 失败率 ≥ 阈值
┌──────────┐                                       ┌────────────┐
│  CLOSED  │ 统计窗口、放行全部请求                 │    OPEN    │ 不发起真实调用
└──────────┘                                       └────────────┘
    ▲ 探测成功数 ≥ 成功阈值，成功后清空窗口             │ 等待 waitDurationInOpenState
    │                  任一探测失败 → 立刻回 OPEN  ┌────────────┐
    └──────────────────────────────────────────────│ HALF_OPEN  │ 只放行 N 个探测
                                                   └────────────┘
状态迁移：CLOSED --失败率越阈值--> OPEN --等待时长结束--> HALF_OPEN --探测成功--> CLOSED

三个状态各回答一个问题：CLOSED 看失败率是否越阈值（必须有最小样本量门槛，否则启动期一次失败就熔断）；OPEN 的拒绝时长是"给下游留的恢复时间”（太短会反复打满未恢复的下游，太长则流量回不来）；HALF_OPEN 用足够小又足够多的探测请求受控验证。

35.4.2 关键参数

35.4.3 熔断与限流的区别

一句话：限流是"我的门有多宽"，熔断是"对面那扇门还能不能走"。只有限流时，下游整体故障会让调用方线程耗在等待上直至线程池耗尽（级联失败）；只有熔断时，下游健康但容量不足不会触发任何保护（没有错误可统计）。

35.4.4 Sentinel 与 Hystrix 的机制差异

Hystrix 进维护模式的根本原因不是功能不足，而是"每个依赖一个线程池“这个抽象在大规模场景成本过高：线程是有限资源，一次调用多花约 1~5 μs 的上下文切换，线程池数量与依赖数成正比，最终线程数成为容量瓶颈（20 个依赖 × 10 线程 = 200 线程）。后续方案都改为同一线程内做滑动窗口统计与信号量限流。要讲清线程池隔离买到了什么：调用发生在另一个线程上，调用方线程可以用 Future.get(timeout) 精确超时并释放自己——即使被调代码不支持中断，调用方也能脱身；代价是工作线程可能仍被阻塞在不可中断的系统调用（如未设读超时的 socket read）上，“丢弃"只是调用方视角的丢弃，线程没被回收，要真正回收须关闭连接或设置 SO_TIMEOUT。而信号量隔离省掉了这次调度，但无法主动超时中断，只能依赖 socket/RPC 超时。

35.5 隔离、超时与重试放大

35.5.1 线程池隔离与信号量隔离

舱壁模式（Bulkhead）的思想是"一个舱进水不该沉船”，落地就是每个依赖拥有独立资源池。它与熔断的时间方向不同：舱壁是事前的（限制同时在飞的调用数），熔断是事后的（观察到失败率过高才停止调用）。二者必须共存：只有舱壁时，持续失败的依赖会反复消耗配额；只有熔断时，在窗口凑满前的那段时间已足以耗尽全局线程池。

35.5.2 超时的层次与重试放大

1
2
3
4
5
6
7
8

入口总预算 3000 ms（用户可接受的极限）
 └─ 网关 2900 ms ─→ 服务 A 2500 ms ─→ 服务 B 1500 ms ─→ 服务 C 800 ms ─→ 数据库/缓存 500 ms
对齐原则：读超时 ≈ 下游 P99.9 × 1.5 且 < 上游剩余预算；连接超时按"握手 1 个 RTT + 余量"给：
   同机房 RTT 0.1~0.5 ms → 500~1000 ms；跨大洲 RTT 约 150 ms → 至少 1~2 s
重试放大：链路 3 层（A→B→C），每层失败时最多尝试 3 次（含首次）且都无条件重试
  A 试 3 次 → 3 个对 B 的请求；每个 B 请求再试 3 次 → 9 个对 C 的请求；每个 C 请求再试 3 次 → 27 个
  放大倍数 = 3³ = 27；入口 1000 QPS（下游正故障）→ 最下游承受 27000 QPS
  若"重试 3 次"指 1 次首发 + 3 次重试 = 4 次尝试，则放大为 4³ = 64 倍

正确的重试有四条要求：只在最外层重试，或每跳只重试一次并带上"已重试次数"头，超过预算即放弃；只对可重试错误重试（连接拒绝/超时、读超时、503、429），对 4xx 业务错误绝不重试；必须幂等（见 35.10 节）；必须配退避与抖动。固定间隔重试会把随机的失败同步成一次脉冲：1000 个客户端在第 0 毫秒同时失败，若无抖动会在第 100 毫秒一起重试，下游在刚恢复的瞬间再次被击穿。**指数退避（exponential backoff）**让第 n 次重试等待 base × 2^n（如 100/200/400 ms）；**抖动（jitter）**把等待随机化，常用满抖动 sleep = random(0, min(cap, base × 2^n))，上例中它把 1000 个请求铺到 0~100 ms 区间，瞬时峰值降到约 1/10。

35.6 降级与兜底

降级的本质是在容量或依赖不可用时，用"功能少一点"换"核心链路还活着”，必须按层次设计，而不是随处 try/catch 返回 null。

触发条件有三类：熔断器打开；超时率/错误率越过阈值（如 1 分钟内超时率 > 10%）；人工开关（大促预案）。“优雅降级"的三条原则：核心链路不可降级（下单、支付的资金流不能降级成"稍后确认”）；每次降级必须有监控与告警，否则降级会长期无声地停在那里；降级开关必须能秒级生效且可灰度，所以要放配置中心（见 35.9 节）。

35.7 链路追踪与日志聚合

35.7.1 TraceID/SpanID 的生成与传播

1
2
3
4
5

用户请求 → 入口（网关）生成 TraceID（128 bit，32 位十六进制）+ 自己的 SpanID(S1, parent=null)
  ──▶ HTTP 头 traceparent: 00-T-S1-01 → 服务 A 生成 S2(parent=S1)，不生成新 traceId
  ──▶ 调 B 时写 traceparent: 00-T-S2-01 → 服务 B 生成 S3(parent=S2)
  ──▶ 发消息时把 T 与 S3 放进消息 Header（Kafka/AMQP headers）→ 消费者生成 S4(parent=S3)
约束：跨进程只传 traceId 与上游 spanId；本进程 spanId 必须本地生成；传播格式必须全链路统一

进程内用线程上下文（ThreadLocal/Context）传递，跨线程池必须显式透传（包装 Runnable、可继承上下文，或用 TransmittableThreadLocal 这类方案），否则异步任务的 span 会挂到错误的父节点上——这是"链路里少了一段"的最常见原因。

35.7.2 OpenTelemetry 与 W3C Trace Context

W3C Trace Context 是标准传播格式：traceparent: 00-<32 位十六进制 trace-id>-<16 位十六进制 parent-id>-<01 采样标志>，另有 tracestate 承载厂商扩展；它的价值是跨厂商、跨语言不丢链路，而 B3（X-B3-TraceId 等私有头）需要网关做格式转换。OpenTelemetry（OTel）的定位是统一的采集标准：一套 API/SDK + 传输协议 OTLP + Collector（接收、处理、导出），同时覆盖 traces/metrics/logs 三类信号；应用只依赖 OTel API，替换后端（Jaeger/Zipkin/商业 APM）只改 Collector 配置。

35.7.3 采样率的取舍：头部采样与尾部采样

算账：1000 QPS × 每请求 10 个 span × 每个 span 约 1 KB = 10 MB/s（约 864 GB/天）；1% 头部采样后约 100 KB/s（约 8.6 GB/天），成本可接受但只能看到千分之一的异常；尾部采样若缓冲 10 秒，Collector 峰值内存约 10 MB/s × 10 s = 100 MB。

35.7.4 与日志聚合配合，以及调用链能回答什么

入口处用日志框架的 MDC（Mapped Diagnostic Context）写入 traceId，日志模板输出 %X{traceId}，同一请求的全部日志即可用一个 traceId 一次拉全。

1
2
3
4
5
6

// 网关过滤器：入口生成 traceId 放进 MDC，同线程后续日志自动携带
String traceId = incoming == null ? TraceId.generate() : incoming; // 上游已有时必须沿用，否则链路断成两段
MDC.put("traceId", traceId);
try { chain.doFilter(request, response); } finally {
    MDC.remove("traceId"); // 必须清理：容器线程复用，不清理会让下个请求带上别人的 traceId
}

调用链恰好回答排障最需要的四个问题：哪一跳最慢（同一链路内 span 时长最长者）；谁在重试（同一父 span 下出现多个同名子 span）；超时发生在哪一层（出现未结束的 span 或错误标记的那一跳）；扇出是否被放大（一个入口 span 下挂了多少下游 span，直接对应 35.5.2 的重试放大）。

35.8 网关的职责边界

Spring Cloud Gateway 与 Zuul 的差异在并发模型而非功能清单：Zuul 1.x 基于 Servlet 阻塞模型，一个请求占一个容器线程，数千长连接下线程成为瓶颈（每线程约 1 MB 栈，且不能无限加）；Spring Cloud Gateway 基于 Reactor/Netty 响应式模型，少量事件循环线程服务大量连接，等待下游时不占线程。代价是编程模型受限：在响应式网关里做任何阻塞调用（JDBC、同步 HTTP、Thread.sleep）都会阻塞 event loop，从而拖死该线程上的所有连接。

35.9 配置中心与灰度发布

配置中心必须同时做到实时推送（长轮询、WebSocket、gRPC stream，让降级与灰度开关秒级生效）与本地快照（拉取后落地本地文件，配置中心不可达时用快照启动）。后者是可用性优先的取舍：配置中心是强依赖，但不该是启动阻塞点，否则一次配置中心故障会连带全部服务无法启动，比配置暂时陈旧危险得多。配置还要有版本、审计与一键回滚。

蓝绿（blue-green）与金丝雀（canary）：蓝绿是两套完整环境，切换瞬间完成（权重 0 → 100），回滚同样瞬间切回，代价是资源翻倍且切换瞬间是全量风险；金丝雀是同一环境内逐步扩大比例（1% → 5% → 50% → 100%），资源占用低、风险递增可控，代价是新旧版本长期共存，接口与数据结构必须双向兼容。

回滚能力比发布能力更重要：发布是计划内动作，回滚多发生在凌晨故障中，此时人的判断力最差，流程必须能在无人决策下执行；回滚要求"上一个稳定版本的镜像还在 + 数据库结构双向兼容”，而数据库变更通常不可逆，所以规范必须规定数据库变更向前兼容：先加列（新旧代码都容忍）→ 双写 → 迁数据 → 再删旧列，每一步都能独立回滚。

35.10 接口幂等性的落地

HTTP 方法语义是速查条目：GET/HEAD 安全且幂等；PUT/DELETE 幂等；POST 非幂等；PATCH 不保证。但方法语义不等于实现保证——POST 创建订单仍必须自己实现幂等。

幂等键的设计是最高频追问点：用业务单据号（订单号、支付流水号、外部请求号）组成键（如 支付:{订单号}:{渠道}），重试时键自然相同，第二次被唯一索引拦下；用随机串（如 UUID）则客户端超时重发会生成新串，去重表拦不住，幂等性直接失效。核心原因：幂等键必须在客户端重试时可复现。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 幂等落地：唯一索引 + 状态机，两条防线各解决一类重复
public PaymentResult pay(String orderNo, String channel, String idemKey) {
    try {
        idempotentMapper.insert(new IdempotentRecord(idemKey, "PROCESSING")); // 幂等键用业务单据号组合
    } catch (DuplicateKeyException e) {
        return loadPreviousResult(idemKey); // 不是第一次请求：读回上次结果，绝不重复扣款
    }
    // 状态机单向迁移：影响行数为 0 说明已被并发请求推进，直接返回幂等结果而不是抛错
    if (orderMapper.updateStatus(orderNo, Status.WAIT_PAY, Status.PAID) == 0) return loadPreviousResult(idemKey);
    doChannelPay(orderNo, channel);
    return PaymentResult.success(orderNo);
}

“幂等"与"并发控制"的区别：幂等解决”同一个请求重复到达"（时间上先后多次、内容相同，结果必须与只执行一次相同，判据是"重复"）；并发控制解决"不同请求同时修改同一资源"（如并发加购不能丢失更新，判据是"并发"）。二者互不蕴含：SET stock = 10 幂等但并发下丢更新（要并发控制）；stock = stock - 1 无并发问题时仍会被重复提交多扣（要幂等）。带绝对版本号的乐观锁同时提供并发控制与"重复提交被拒"的效果，因此常被误认为幂等方案——它其实是靠"版本不匹配"拒绝了第二次提交，前提是客户端重发时携带同一个版本号。

35.11 微服务的调试与排障

跨服务问题的定位流程（不要一上手就翻单机日志）：① 从用户反馈的请求拿到入口 traceId，在日志聚合里拉取该链路全部日志并按时间排序；② 在链路追踪里按 span 时长找最慢的一跳，并检查是否出现同名 span 的多次出现（说明发生重试）；③ 判断是单实例问题还是整体问题，把同一接口按实例维度看错误率与 P99，集中在某实例就去查该实例的 CPU/GC/连接池/磁盘；④ 检查是否被资源池限制（HikariCP 等待、线程池队列堆积、下游限流 429）；⑤ 对比失败与成功请求的差异维度（用户、地域、实例、依赖版本），这一步经常直接暴露灰度引入的回归。

时间同步（NTP）为什么是前提：span 时长由各机器自己的时钟算出，若两台机器偏差超过调用跨度，就会出现"子 span 在父 span 之前结束"这类不可能的时序，把责任定位到错误的一跳，日志聚合按时间排序也会错乱。经验判据是偏差超过 100 ms 时跨机时序结论不可信；容器环境要注意看宿主机时钟而非容器内时钟。

1
2
3

# 按 traceId 拉全链路日志（已由 MDC 写入）；时钟偏差超过 100 ms 时 span 时序结论作废
grep -h "<traceId>" /var/log/app/*.log | sort -k1,2; chronyc tracking | grep -E 'System time|Last offset'
grep -c "call=inventory.deduct" trace-export.jsonl   # 同名 span 出现多次，说明该跳在重试

本地难以复现时的三件套：影子流量（shadow traffic）——在生产入口按比例复制流量到新版本，读路径直接对比返回差异，写路径必须隔离（打标不落真实库或写影子表），否则污染生产数据；链路重放（replay）——记录入口请求与下游响应，本地按录制回放依赖，把"偶发"变成"必现"，这是解决时序类 bug 最有效的手段；只读降级演练——把写操作临时降级为只读沙箱，在生产流量下验证读路径与新版本逻辑。

本章小结

自测题

Q1（计算）链路为 网关 → 订单服务 → 库存服务 → 数据库，共 3 层跨进程调用，每层失败时最多尝试 3 次（含首次），入口 QPS 为 2000。求最坏情况下数据库承受的请求量，并说明为什么这个参数必须配重试预算。

Q2（辨析）“熔断和限流都是流量过大时保护系统，实现一个就够了。“请指出错在哪，并分别给出一个只有限流会失效、只有熔断会失效的场景。

Q3（推导）Eureka 的自我保护触发后不再剔除续约过期的实例。请说明它在什么条件下触发、为什么是有意设计，以及"保留过期实例"的代价由谁承担。

Q4（设计）一个下单接口需要幂等。请给出至少两种方案，说明各自防住哪类重复，并辨析"幂等"与"并发控制”。

Q5（判断）“服务端发现（如 Kubernetes Service）对客户端完全透明，所以客户端不再需要任何负载均衡与重试逻辑。“判断正误并说明理由。

面试高频问题与陷阱

延伸阅读

• W3C Recommendation：Trace Context（traceparent/tracestate 字段定义与采样标志位语义）。
• OpenTelemetry 官方文档：Specification 中的 Tracing API、Context 传播与 Sampling 章节，以及 OTLP 协议与 Collector 的 tail_sampling 处理器。
• Resilience4j 官方文档：CircuitBreaker（滑动窗口类型、阈值、waitDurationInOpenState、permittedNumberOfCallsInHalfOpenState）与 Bulkhead/Retry/TimeLimiter 模块。
• Sentinel 官方文档：滑动窗口统计实现（LeapArray）、流控与降级规则；Netflix Hystrix 官方 wiki：Configuration 页（线程池核心数、requestVolumeThreshold、sleepWindowInMilliseconds）与维护模式说明。
• Kubernetes 官方文档：Service 与 kube-proxy 的 iptables/IPVS 模式、Ingress/Gateway API、三种探针语义。
• Spring Cloud Gateway 官方文档：Reactor/Netty 模型与 Zuul 1.x 的比较、GatewayFilter 与限流集成。
• 配套章节：第 34 章（CAP、一致性哈希、限流算法、分布式锁理论）、第 27 章（Redis 命令与锁实现细节）、第 33 章（消息队列视角的幂等与削峰）。