1. 课程导论：为什么需要错误处理与事务边界？Kafka 在分布式系统中的角色与挑战
在构建现代分布式系统时，消息中间件（尤其是 Apache Kafka）已成为数据中枢。然而，随着微服务拆分粒度变细、异步通信链路变长，一个核心问题逐渐浮现：当系统局部发生故障时，如何保证数据不丢、不重、不乱？ 这正是本课程要解决的根本矛盾——错误处理、事务边界与消息链路的一致性设计。
1.1 分布式系统中的典型困境
假设一个电商订单流程：用户下单 → 扣减库存 → 发送短信通知。如果使用 Kafka 异步解耦，每个步骤都可能失败：
- 生产者发送失败：订单已保存到数据库，但消息未写入 Kafka，导致下游库存服务未收到指令。
- 消费者处理失败：库存扣减成功，但消费者在提交 offset 前崩溃，重启后重复扣减。
- 事务边界模糊：数据库操作与 Kafka 发送不在同一个本地事务中，出现“订单已落库、消息未发出”的不一致状态。
核心痛点：分布式系统中，本地事务（ACID）无法跨网络边界。Kafka 作为中间层，必须与业务数据库协同，形成分布式事务或最终一致性方案。
1.2 Kafka 在分布式系统中的角色
| 角色 | 说明 | 典型场景 |
|---|---|---|
| 事件总线 | 解耦生产者与消费者，支持发布/订阅模式 | 订单状态变更通知、用户行为采集 |
| 流处理平台 | 支持 Kafka Streams / ksqlDB 进行实时计算 | 实时风控、实时大屏聚合 |
| 持久化日志 | 消息持久化到磁盘，支持回溯重放 | 事件溯源、审计日志、数据同步 |
| 系统解耦缓冲 | 削峰填谷，抵御下游突发流量 | 秒杀系统、IoT 设备数据上报 |
Kafka 的高吞吐、持久化、分区并行特性使其成为分布式系统的首选消息中间件，但也带来了至少一次（At-Least-Once） 和 精确一次（Exactly-Once） 语义的权衡挑战。
1.3 Kafka 带来的核心挑战
- 消息可靠性语义：Kafka 默认提供“至少一次”投递，但业务场景往往需要“精确一次”。如何实现？
- 事务边界不一致：数据库事务与 Kafka 发送操作无法在同一个 ACID 事务中完成，需要引入“本地消息表”或“事务消息”模式。
- 消费者幂等性：即使消息只投递一次，消费者处理失败后重试也可能导致业务重复执行。
- 死信与重试策略：消息处理失败后，是无限重试还是进入死信队列？如何设计重试退避策略？
- 链路追踪与补偿：跨多个微服务的消息链路如何追踪？出现最终不一致时如何补偿？
常见误区：很多团队认为只要引入 Kafka 就能自动解耦，却忽略了错误处理和事务边界设计。结果往往是“消息不丢但业务乱”、“链路通了但数据对不上”。
1.4 错误处理与事务边界的必要性
从系统设计角度看，错误处理和事务边界不是可选项，而是生产级系统的必备能力：
- 数据一致性：防止因局部故障导致全局数据不一致。
- 系统韧性：通过重试、死信、补偿机制让系统在故障中自动恢复。
- 可观测性：清晰的错误链路和事务边界便于排查问题。
- 运维成本：良好的设计能大幅减少人工介入修复数据的时间。
1.5 课程核心内容预览
本课程将围绕以下主线展开，帮助您构建生产级的 Kafka 消息链路：
| 模块 | 核心内容 | 关键产出 |
|---|---|---|
| 错误处理基础 | 重试策略、退避算法、死信队列设计 | 可复用的错误处理框架 |
| 事务边界设计 | 本地消息表、事务消息、Kafka 事务 API | 数据库与 Kafka 的一致性方案 |
| 幂等消费实现 | 去重表、状态机、幂等性保证 | 精确一次消费模式 |
| 链路追踪与补偿 | TraceId 传递、Saga 补偿、最终一致性监控 | 全链路可观测性方案 |
| Spring Boot 集成 | KafkaTemplate、@KafkaListener、事务注解 | 可直接运行的代码示例 |
学习建议：本课程适合有一定 Kafka 和 Spring Boot 基础的开发者。建议在学习过程中动手搭建一个简单的订单流程，逐步引入错误处理和事务边界，观察不同策略下的行为差异。