当前位置：首页 > ds >正文

通过分布式系统的视角看Kafka

ds 2025/8/20 10:23:43

希望这篇文章能对我有意义
2025年8月16日
以一个分布式系统的视角看kafka，kafka就不会只是一个生产者消费者模型那么简单。
以下都是一些

服务发现，服务注册

kafka中会有KRaft 元数据管理（取代 ZooKeeper）进行服务发现与注册
用于管理分区状态

服务调用

服务调用就是consumer和producer。

远程服务调用

该分布式内交互方式是发送数据以及消费数据，方式就是Http

负载均衡

操作的中心就是Partition
一个partition对应一个consumer，一组consumer共用一个offset，这个offset存储在partition内。
一个合理的负载均衡策略可以保证开发的稳定进行，常见的kafka partition负载均衡策略（分区策略）是RangeAssignor 策略（时间分区），RoundRobinAssignor 策略（轮询分区），StickyAssignor 策略（原有的分配结果不变，新增的partition会分给原有consumer）

容错机制

对于kafka，容错就是ISR机制（broker容错），生产者ACK机制，消费者的心跳检测与offset机制

常见的容错机制如下：

容错策略	核心思想	适用场景	典型实现系统
Failover	主故障切换备份，支持重试	读操作、幂等服务	HDFS、Dubbo110
Failfast	失败立即报错，不重试	非幂等写操作（支付）	Dubbo、Java集合810
Failsafe	忽略异常，保主流程	日志、监控等旁路逻辑	Dubbo710
Failback	异步存储+定时重试	最终一致性（库存同步）	Dubbo、消息队列37
Forking	并行调用，任一成功即返回	高可用读操作	Dubbo710
Broadcast	广播所有节点，全部成功才成功	配置同步、缓存更新	Dubbo、Cassandra37

一致性算法

数据一致性

一致性算法保证分布式系统下数据不被丢失，重心就在于broker
如果Leader节点挂掉，就会触发Controller 选举（基于 Raft 协议），过于落后的Follower不会再参与到选举中

消费一致性

HW（高水位线）机制：标识已提交消息的偏移量，消费者仅能读取HW以下数据，避免脏读
Leader Epoch：防止脑裂场景下数据不一致，新Leader基于Epoch号截断旧数据

日志、链路调用、指标监控

日志：
kafka的数据就是日志，

链路追踪：
kafka自身不支持链路追踪能力

端到端延迟分析：结合外部工具（如Prometheus+Grafana）监控生产→Broker→消费全链路时延38。

监控：
Kafka 通过 JMX（Java Management Extensions）暴露丰富运行时指标，是监控体系的核心基础：