前阵子排查一个使用者 rebalance 的问题，翻到 Kafka 源码里去了。本来只想看看协调器怎么工作的，结果发现 Kafka 的设计模式用得相当精妙——不是教科书式的"定义接口→实现类→调用"。而是把多个模式揉在一起解决真实问题。

很多人学设计模式停留在"观察者就是 EventBus"这个层面但 Kafka 的观察者模式跟教科书完全不是一个物种。今天拆几个 Kafka 源码里最有意思的设计模式，看完你可能得重新审视自己写的代码。

再看观察者模式。Consumer Group 的协调机制

教科书里的观察者模式：一个 Subject，N 个 Observer，状态变了通知一下。完事，

Kafka 的使用者组协调机制也是观察者，但它解决的问题复杂得多：

• 不是简单的"状态变了通知一下"，而是"状态变了之后所有人要协商出一个新的一致状态"
• 观察者可以随时加入和离开
• 通知不是一次性的。而是一个多轮的 rebalance 协议

private void onJoinComplete {
// rebalance 完成后的回调——每个使用者拿到自己的分区分配
// 这不是简单的 notify，而是一个分布式协商的终点
}

说到关键点，Kafka 的协调器不是简单广播状态，而是通过 JoinGroupRequest → SyncGroupRequest 两轮交互完成一次 rebalance。第一轮选 leader，第二轮由 leader 做分区分配，再把结果分发下去。

如果你只是把使用者写成“监听事件”。就会忽略掉多轮协商和动态成员管理导致的重平衡成本，这正是你在高并发环境下频繁出现消费暂停、延迟突增的问题根源。

你写的观察者模式是"通知一下"，Kafka 的观察者模式是"通知→协商→确认→生效"。这个差距不是代码量的差距，是问题域的差距。

再看策略模式，分区分配策略的可插拔设计

Kafka 的分区分配策略是个教科书级的策略模式。但它有一个很多人忽略的设计决策：默认不是 RoundRobin.

public interface PartitionAssignor {
Map assign(Cluster metadata,Map subscriptions);}
class RangeAssignor implements PartitionAssignor { ... }
class RoundRobinAssignor implements PartitionAssignor { ... }
class StickyAssignor implements PartitionAssignor { ... }

曾经用 RoundRobin 分配策略时使用者数变化会导致几乎所有分区重新分配，导致频繁的数据热迁移和缓存失效；改用 StickyAssignor 后只移动必要的分区，明显提高缓存命中率与整体吞吐。

这个案例说明一个策略模式的选型问题：策略不能只看“对不对”。要看“切换代价大不大”. RoundRobin 逻辑没错，但每次 rebalance 的代价太高。

责任链模式的观点是。Producer 的 Interceptor 链

不少人不知道 Kafka Producer 有拦截器机制，因为它默认是空的。但这个设计非常典型：

public interface ProducerInterceptor extends Configurable {
ProducerRecord onSend;void onAcknowledgement;void close，}
...
private Future doSend {
ProducerRecord intercepted = interceptors == null?record : interceptors.onSend;...
}

如果你想在发送过程中做日志、监控或安全校验，一味地往 send 方法里塞代码会导致低吞吐与高耦合；使用拦截器链可以将关注点解耦，同时保持极低延迟。

实际用法示例的观点是，

1. onSend：给消息打时间戳和链路追踪 ID。说起来，
2. onAcknowledgement：Ack 后统计发送成功率和延迟。

这两件事加起来只增加不到百分之一秒延迟。却让监控粒度提高数十倍，让你能精准定位生产瓶颈与异常情况。

模板方法模式这方面，KafkaProducer 的发送流程

KafkaProducer.send 方法是模板方法模式的经典实现，只是它没用抽象类。而是用固定流程 + 多个可替换组件：

public Future send(ProducerRecord record,Callback callback) {
// 拦截器处理
ProducerRecord intercepted = interceptors.onSend;不过，// 序列化
byte serializedKey = keySerializer.serialize;byte serializedValue = valueSerializer.serialize;// 分区选择
int partition = partitioner.partition;// 添加到批次
RecordAccumulator.RecordAppendResult result =
accumulator.append;// 唤醒 Sender 线程
if
sender.wakeup;return result.future;}

如果你手动实现自己的发送逻辑。很容易忘记某一步，如批次管理或唤醒网络线程，从而导致吞吐下降或阻塞。老实说，使用模板方法可以保证流程完整且可 同时易于维护。

工厂 + 门面：Kafka 客户端创建简化方案

KAFKA 客户端创建涉及大量内部组件配置，如 NetworkClient、Serializer、Accumulator、Sender 等。如果让使用者自己组装，很容易出错或遗漏关键设置。其实，

KafkaProducer
producer = new KafkaProducer<>;// 内部构造函数做了大量组装工作
// - metrics、serializer、partitioner、accumulator、sender...
// - 网络线程初始化并启动
// - 配置驱动动态创建各组件

• 门面这方面，使用者只需传入一份配置即可得到完整功能比较全面的 Producer 或 Consumer 实例。
• 工厂的观点是。通过配置动态实例化 Serializer、Partitioner 等插件，实现高度可插拔与可定制化。其实，
• 避免使用者因手动组合导致错误配置。从而引发不可预期的问题，
• 保持内部组件解耦，让未来升级更容易、更安全。
• 极大降低使用门槛，让更多团队快速上手并专注业务业务逻辑。

关键洞察 &   

1. 观察者不只是“notify”。也能做“协商” - 当程序需要动态成员加入/离开且必须保持一致性时多轮协议比一次性通知更可靠，可避免数据漂移与冲突；缺少此步骤常导致消费停顿或乱序等痛点。
2. 策略选择需考虑切换代价 s- 用 RoundRobin 则产生大量数据迁移，引起缓存失效；Sticky 更稳定，减少重平衡成本；评估业务需求后再决定即可避免无谓重启开销。
3. 责任链取舍要跟性能目标对齐 - 将拦截器限制为两钩子可保证极低延迟；若想全链路拦截，则需要权衡额外 CPU 与网络负载，避免吞吐骤降。
4. 模板方法+插件化比更好继承程序 - 固定流程+可插拔组件既保证一致性。又允许灵活 相比传统抽象类更易维护，也更贴合高并发环境需求。按理说，
5. 工厂+门面简化客户端创建 - 隐藏内部细节。让使用者无需关心几十个依赖关系即可获得健壮客户端；其实，避免错误组合导致运行时崩溃。说起来，