第4周：中间件与分布式

本日概要

把关系型数据库看成由连接与解析层、优化器和存储引擎组成的分层系统。InnoDB 的主键是聚簇索引，行数据就存放在主键 B+ 树的叶子上；二级索引叶子存的是主键值，因此不能被索引覆盖的查询需要回表。ACID 中的隔离性由四个隔离级别与 MVCC、行锁、间隙锁共同实现，脏读、不可重复读和幻读分别在不同级别被挡住。分库分表能缓解单机容量与写入压力，但会引入跨分片查询、全局主键和数据迁移等新成本，只有在有实测证据时才应该讨论。

学习目标

• 能画出一次 SELECT 从连接层、优化器到存储引擎的处理路径，并说明各层能观察到什么
• 能解释聚簇索引与二级索引的存储差异，并用最左前缀、回表和覆盖索引判断一个索引是否会被用上
• 能把脏读、不可重复读、幻读分别对应到隔离级别，并说明行锁与间隙锁在其中的作用
• 能读懂 EXPLAIN 的 type、key、rows、Extra 字段，并把结论绑定到表结构、数据量和 MySQL 版本

核心讲解

实践任务

在本人授权的本地 MySQL 实例中构造一张有数据的测试表，用 EXPLAIN 对比命中索引、回表和全表扫描三种执行计划，并记录版本、表结构、行数与原始输出。

• 在本人授权的本地实例中创建一个专用测试库和随机后缀表名，插入至少十万行可复现的伪造数据，记录 MySQL 版本、表结构与行数。
• 对同一个查询分别在无索引、有二级索引但需回表、有覆盖索引三种情况下执行 EXPLAIN，保存三份原始输出，重点对比 type、key、rows 和 Extra。
• 写一条会退化为全表扫描的查询（例如在索引列上使用函数或以通配符开头的 LIKE），用 EXPLAIN 证明它没有用上索引，并解释原因。
• 把三组观察整理成结论，明确标出哪些是本次实验条件下的事实、哪些是推断；实验结束后删除本人创建的测试库并记录删除结果。

自测与答案

今日完成标准

• 提交三份 EXPLAIN 原始输出，并逐份说明 type、key、rows、Extra 反映了哪种访问路径
• 用自己的话写出聚簇索引、二级索引、回表和覆盖索引的关系，并给出一个会失效的联合索引例子
• 实验记录包含 MySQL 版本、表结构、数据量和清理结果，结论区分事实与推断

常见错误与纠正提示

• 认为「建了索引就一定会用」，忽略最左前缀、函数包裹列和前导通配符会让索引失效
• 把隔离级别当成性能开关随意调低，却没有说明放开了哪一类读异常
• 只看查询耗时不看执行计划，把一次缓存命中的快速响应当作索引生效的证据

分层任务

关联知识点

• 数据库

延伸阅读

• MySQL 8.4 Reference Manual: Clustered and Secondary Indexes（Oracle MySQL 官方参考手册）
• MySQL 8.4 Reference Manual: Transaction Isolation Levels（Oracle MySQL 官方参考手册）
• MySQL 8.4 Reference Manual: InnoDB Locking（Oracle MySQL 官方参考手册）
• MySQL 8.4 Reference Manual: EXPLAIN Output Format（Oracle MySQL 官方参考手册）

本日概要

Redis 与 MongoDB 解决的是关系型数据库不擅长的问题，但各自有明确边界。Redis 的价值来自数据结构本身：字符串、哈希、列表、集合、有序集合和位图分别对应不同访问模式，排行榜用有序集合、去重用集合、会话用哈希；它的命令在单线程事件循环中执行，因此一条慢命令或一个超大 key 会阻塞整个实例。MongoDB 的核心决策是内嵌还是引用，以及写关注级别要不要等待多数节点确认。缓存部分的难点不是「加缓存」，而是一致性：更新顺序、穿透、击穿、雪崩各有不同成因和不同缓解手段。

学习目标

• 能为排行榜、去重、会话、计数、消息队列等场景各选出合适的 Redis 数据结构并说明理由
• 能解释 Redis 单线程执行模型如何把大 key 与慢命令放大成实例级延迟
• 能在 MongoDB 中判断一份数据应当内嵌还是引用，并说明写关注级别对持久性的影响
• 能区分缓存穿透、击穿、雪崩的成因，并为每种情况给出一个可验证的缓解手段

核心讲解

实践任务

用本人本地的 Redis 实例实现一个带过期时间的排行榜与一段旁路缓存逻辑，构造缓存未命中、缓存穿透和批量同时过期三种情况并记录观察。

• 在本人授权的本地 Redis 中用带随机前缀的 key 建立一个有序集合排行榜，写入若干成员与分数，用按排名取区间的命令验证结果顺序。
• 实现一段旁路缓存读写逻辑：读未命中时回填并设置过期时间，写操作后使缓存失效；记录一次未命中和一次命中的完整调用序列。
• 构造缓存穿透：反复查询一个数据库中不存在的 key，观察回源次数；再加入空值缓存后重复实验并对比。
• 把一批 key 设置为同一过期时刻，观察集中过期后的回源峰值；改为过期时间加随机抖动后重复，记录两次差异并清理本次实验创建的所有 key。

自测与答案

今日完成标准

• 提交排行榜与旁路缓存的可复现操作记录，包含 Redis 版本、命令序列和原始返回
• 用实验数据说明穿透与集中过期两种情况下回源次数的变化，并解释缓解手段为何有效
• 写出本次实现中不一致窗口出现的位置与最长持续时间的估计，并标明这是推断还是实测

常见错误与纠正提示

• 把 Redis 当成「更快的数据库」直接存放需要强持久性的业务主数据，却没有评估丢失窗口
• 用一句「加缓存」概括方案，不说明失效策略、过期时间和不一致窗口
• 在生产实例上用 KEYS 或无界范围命令做排查，把排查动作本身变成故障

分层任务

关联知识点

• 数据库

延伸阅读

• Redis Data Types（Redis 官方文档）
• Redis Sorted Sets（Redis 官方文档）
• Redis Latency Troubleshooting（Redis 官方运维文档）
• MongoDB Manual: Data Model Design（MongoDB 官方手册）
• MongoDB Manual: Write Concern（MongoDB 官方手册）

本日概要

消息队列把同步调用变成异步事件，但也把「调用失败」变成了「投递语义」问题。Kafka 以分区为并行单位，每个分区是一个有序、可重放的提交日志，消费者组通过位点提交决定进度；顺序保证只在分区内成立。RabbitMQ 用交换机、绑定和队列描述路由，直连、主题、扇出等交换机类型对应不同分发模式。至少一次、至多一次、恰好一次都有成立条件：只要存在重试，消费端就必须自己做幂等。设计时要同时画出重复投递、消费失败、积压和死信这四条失败路径，而不是只画正常流程。

学习目标

• 能解释 Kafka 的分区、副本、消费者组和位点如何共同决定并行度与顺序保证的边界
• 能用交换机、绑定、路由键描述 RabbitMQ 的一次消息分发，并说明它与 Kafka 模型的差异
• 能判断一个消费流程属于至少一次还是至多一次，并说明恰好一次的成立条件
• 能为重复投递、消费失败、积压、死信四条失败路径各写出一个可执行的处置动作

核心讲解

实践任务

为一个订单事件设计可重放的消费流程，说明分区键、位点提交时机、幂等键与死信处理，并用本地实例或教师证据包验证重复投递时的结果。

• 为订单事件选定分区键并说明理由，画出生产者、分区、消费者组和位点提交时机的关系图。
• 定义幂等键与去重存储，写出消费端处理伪代码，明确「先处理后提交位点」还是「先提交后处理」以及对应的语义。
• 在本地实例或教师证据包中人为重复投递同一条消息，记录去重前后的业务结果差异与原始日志。
• 设计重试与死信策略：写明最大重试次数、退避方式、死信队列名称、告警条件与重投前的人工检查项。

自测与答案

今日完成标准

• 提交包含分区键、位点提交时机、幂等键和死信路径的事件消费设计图
• 用重复投递实验的原始记录证明幂等逻辑生效，并说明去重存储的过期策略
• 为重试次数、退避时间和死信告警各给出具体数值，并说明这些数值的依据是实测还是假设

常见错误与纠正提示

• 只画正常流程图，不写重复、失败、积压和死信这四条路径的处置动作
• 把消息队列当成「异步就一定更可靠」，忽略积压时延迟会以另一种形式暴露给用户
• 依赖中间件的投递语义承诺而不做业务幂等，重试时造成重复扣款或重复发货

分层任务

关联知识点

• 消息队列

延伸阅读

• Apache Kafka Documentation: Design（Apache Kafka 官方文档）
• Apache Kafka Documentation: Message Delivery Semantics（Apache Kafka 官方文档）
• RabbitMQ: AMQP 0-9-1 Model Explained（RabbitMQ 官方教程）

本日概要

CAP 讨论的是网络分区真实发生时，系统在一致性与可用性之间必须做出的取舍，而不是平时可以任选两项。把它与 PACELC 一起看才完整：没有分区时，延迟同样是要付的代价。真正影响设计的是一致性模型的层次——线性一致性、顺序一致性、因果一致性、最终一致性对客户端的可见性承诺各不相同，Jepsen 的一致性模型索引把它们的强弱关系整理成了可查的谱系。落到订单场景，需要回答的是：哪些数据必须强一致，哪些可以接受收敛窗口，收敛期间界面显示什么，以及如何对账。

学习目标

• 能准确陈述 CAP 的前提是网络分区已经发生，并说明「三选二」这一通俗表述的误导之处
• 能用 PACELC 解释无分区时延迟与一致性之间的取舍
• 能按强弱顺序排列线性一致性、因果一致性和最终一致性，并说明各自对客户端的承诺
• 能为一个业务场景逐项指定一致性要求，并写出收敛窗口内的界面表现与对账方案

核心讲解

实践任务

为一个订单场景画出一致性边界：逐项标注库存、支付、订单状态、物流和统计各自要求的一致性级别、可接受的收敛窗口与对账机制。

• 列出订单场景中的五类数据：库存、支付状态、订单状态、物流轨迹、运营统计，逐项写出业务上不可接受的错误现象。
• 为每一项指定一致性要求，并从 Jepsen 一致性模型索引中选出对应的模型名称，避免使用「强一致」「弱一致」这类含糊表述。
• 对可以接受最终一致的项，写出收敛窗口的估计值、窗口内的界面表现，以及用户在窗口内重复操作时的处理方式。
• 为至少两项设计对账机制：对账数据来源、对账周期、发现不一致后的修复动作和人工介入条件；标明哪些数值是实测、哪些是假设。

自测与答案

今日完成标准

• 提交一致性边界表，五类数据逐项给出一致性模型名称、收敛窗口与不可接受的错误现象
• 至少两项配有可执行的对账方案，包含数据来源、周期与修复动作
• 文档中区分事实、推断与待验证假设，收敛窗口数值标明来源

常见错误与纠正提示

• 把 CAP 表述成「三选二」，据此声称系统「放弃了一致性」
• 对整个系统只给一个笼统的一致性级别，不按数据项拆分
• 承诺最终一致却不定义收敛窗口、界面表现和对账方式，出问题时无法判断是否异常

分层任务

关联知识点

• 大数据平台

延伸阅读

• Jepsen: Consistency Models（Jepsen 一致性模型索引）
• Jepsen: Linearizability（Jepsen 一致性模型条目）

本日概要

跨服务的一致性没有免费方案，只有代价不同的方案。两阶段提交依赖协调者投票，语义清晰但在协调者故障时参与者可能长时间持锁阻塞，跨服务长事务代价很高。TCC 把「预留—确认—取消」写进业务接口，控制力强但侵入业务。Saga 用一串本地事务加补偿动作换取可用性，代价是中间态对外可见。本地消息表和事务消息把一致性问题转化为可重试的投递问题。无论选哪种，都必须回答：失败点在哪里、补偿边界到哪里、补偿本身是否幂等、什么情况下需要人工介入。

学习目标

• 能说明两阶段提交的阻塞来源，并判断哪些场景不适合使用它
• 能用「预留—确认—取消」描述 TCC 的三个阶段，并指出它对业务接口的侵入
• 能为一个跨服务流程设计 Saga 的补偿序列，并说明中间态对外的可见性
• 能论证补偿动作必须幂等的原因，并给出实现幂等的具体手段

核心讲解

实践任务

为一个跨订单、库存、支付三个服务的下单流程，分别用 Saga 和本地消息表画出正常路径与补偿路径，并逐个失败点写出处置动作。

• 画出下单流程的正常路径：订单创建、库存预留、支付扣款、订单确认，标出每一步的本地事务边界。
• 为每一步写出对应的补偿动作，并逐个判断该补偿是否会产生新的外部影响（如通知、账目记录）。
• 标出至少四个失败点：库存不足、支付超时未知结果、补偿失败、补偿请求先于正向请求到达；为每个失败点写出处置动作与人工介入条件。
• 为补偿设计幂等键与状态机，说明如何防止空补偿与悬挂，并把方案与本地消息表方案在实现成本、可观测性、恢复难度上做对比。

自测与答案

今日完成标准

• 提交 Saga 与本地消息表两种方案的流程图，正常路径与补偿路径都完整
• 至少四个失败点各有明确处置动作、重试策略与人工介入条件
• 补偿幂等方案写明幂等键、状态机与空补偿处理，并对两种方案做出有依据的取舍结论

常见错误与纠正提示

• 把补偿说成回滚，忽略中间态已被用户和外部系统看到
• 只设计正向流程的重试，不设计补偿失败后的处置，导致故障时无人负责
• 补偿动作不做幂等，重试后产生重复退款或重复释放库存

分层任务

关联知识点

• 数据库

延伸阅读

• Azure Architecture Center: Saga Design Pattern（Microsoft 官方架构模式文档）
• Azure Architecture Center: Compensating Transaction Pattern（Microsoft 官方架构模式文档）

本日概要

网关处理南北向流量：路由、认证、限流、熔断和协议转换集中在系统入口，一个组件即可对外收敛策略。服务网格用边车代理接管东西向流量，把重试、超时、流量切分和 mTLS 从业务代码下沉到基础设施，Istio 用 VirtualService 与 DestinationRule 这类配置对象描述这些规则。两者职责有重叠但不等价，叠加使用会增加一跳延迟与排障复杂度。灰度发布的关键是分流依据——按权重还是按请求头，二者的可复现性与可回滚性完全不同；故障隔离则依赖舱壁、超时预算和可观测指标。

学习目标

• 能区分南北向与东西向流量，并说明网关与服务网格各自的职责边界
• 能用 Istio 的流量管理概念描述一次按权重或按请求头的灰度分流
• 能解释 mTLS 在服务网格中解决了什么问题，以及它不解决什么问题
• 能为一个服务设计超时、重试与舱壁参数，并说明这些参数之间必须相容的原因

核心讲解

实践任务

为一个已有服务设计灰度发布与故障隔离方案，写出分流规则、超时与重试预算、回滚触发条件和需要观察的指标。

• 选定一个服务，画出请求从客户端经网关到服务、再到下游依赖的完整路径，标出 TLS 终止点、认证点和限流点。
• 设计灰度规则：写出分流依据（权重或请求头）、初始比例、放量步骤与每一步的观察时长，并说明为何选择该依据。
• 写出超时与重试预算表：每一跳的超时值、重试次数与退避策略，并验算上游超时是否大于下游超时与重试的总和。
• 定义回滚触发条件与观察指标（如错误率、P99 延迟、饱和度），写明阈值、观察窗口与决策人；标注哪些阈值来自历史数据、哪些是初始假设。

自测与答案

今日完成标准

• 提交包含 TLS 终止、认证、限流位置的请求路径图，并区分南北向与东西向治理点
• 灰度方案写明分流依据、放量步骤、观察指标与回滚触发条件
• 超时与重试预算表通过相容性验算，并说明各数值的来源是历史数据还是初始假设

常见错误与纠正提示

• 同时叠加网关与服务网格却没有划分职责，导致同一策略在两处配置且互相覆盖
• 认为启用 mTLS 就等于完成了安全治理，忽略接口级授权仍需单独配置
• 灰度只定义放量比例，不定义回滚条件与观察指标，出问题时只能凭感觉决策

分层任务

关联知识点

• 云计算

延伸阅读

• nginx: HTTP Load Balancing（nginx 官方文档）
• Istio: Traffic Management Concepts（Istio 官方文档）
• Istio: Security Concepts（Istio 官方文档）
• Kong Gateway Documentation（Kong 官方开发者文档）

本日概要

本周收尾不引入新组件，而是把数据库、缓存、消息队列、分布式事务与流量治理整理成一棵可复核的选型决策树。合理的提问顺序是：数据形态与一致性要求是什么，吞吐与延迟目标是多少，团队的运维与安全边界在哪里，最后才是选哪个产品。每个分支都要写出触发条件、被放弃方案的原因和回退路径；价格、容量这类易变数字应标记为需要在实际选区重新核验的假设，而不是写死在报告里。这份决策树也是第 4 周作业与阶段项目的骨架。

学习目标

• 能按「数据形态与一致性 → 吞吐与延迟 → 运维与安全边界 → 产品」的顺序组织选型提问
• 能为每个决策分支写出触发条件、放弃其他方案的理由和回退路径
• 能识别报告中哪些数字是易变假设，并给出重新核验的入口而不是直接写死
• 能把本周的一致性、幂等、补偿和流量治理结论串成一个可复核的整体方案

核心讲解

实践任务

把本周五天的结论整合成一份中间件选型决策树，并用一个电商或内容平台的具体场景走通至少两条完整分支。

• 把本周五天的核心结论各摘录两条，标注它属于机制性结论还是与版本/规格相关的易变事实。
• 绘制决策树：第一层按数据形态与一致性要求分支，第二层按吞吐与延迟目标分支，第三层按运维与安全边界分支，叶子节点才是候选方案。
• 选定一个电商或内容平台场景，沿决策树走通至少两条完整分支，逐节点写出触发条件、放弃理由和回退路径。
• 列出报告中所有易变数字，为每一项给出官方核验入口、本次访问日期和低中高三档用量情景；未核验的一律标记为待验证假设。

自测与答案

今日完成标准

• 提交三层结构的中间件选型决策树，叶子节点为候选方案而非产品排名
• 至少两条完整分支写出触发条件、放弃理由和回退路径，并对应到一个具体业务场景
• 易变数字清单完整，每项有核验入口与访问日期，未核验项被明确标记为待验证假设

常见错误与纠正提示

• 决策树只有产品名而没有触发条件，别人无法按同样条件复核
• 把某次基准测试结果当作产品的固有性能，忽略负载、并发与版本条件
• 报告中混排稳定的机制结论与易变的价格规格，导致整份文档很快过期

分层任务

关联知识点

• 数据库
• 消息队列

延伸阅读

• MySQL 8.4 Reference Manual: Clustered and Secondary Indexes（Oracle MySQL 官方参考手册）
• Redis Data Types（Redis 官方文档）
• Apache Kafka Documentation: Message Delivery Semantics（Apache Kafka 官方文档）
• Azure Architecture Center: Saga Design Pattern（Microsoft 官方架构模式文档）
• Istio: Traffic Management Concepts（Istio 官方文档）