这是一篇关于Kafka的简单总结,主要偏向于Kafka中的各个概念术语的意思,以及使用场景,使用时需要考虑的问题,但这并不是结束,Kafka中有些关键参数的意义和使用方式,具体的使用案例启示并没有说,这些日后再补充,没有那么多的源码解析,因为源码太多了贴着累,其实这些中间件,更多的在于原理的理解,巧妙的设计,视野的拓展,结合场景的使用

kafka介绍

kafka是一个流式分布式消息系统,早期由LinkedIn公司开发用于活动流和运营数据处理管道的基础支持,后发展为一个高性能、支持大量消息堆积的消息系统

kafka适用场景

  • 实时处理支付和金融交易,例如在证券交易所、银行和保险中。
  • 实时跟踪和监控汽车、卡车、车队和货物,例如物流和汽车行业。
  • 持续捕获和分析来自 IoT 设备或其他设备(例如工厂和风电场)的传感器数据。
  • 收集客户互动和订单并立即做出反应,例如在零售、酒店和旅游行业以及移动应用程序中。
  • 监测住院病人并预测病情变化,以确保在紧急情况下得到及时治疗。
  • 连接、存储和提供公司不同部门产生的数据。
  • 作为数据平台、事件驱动架构和微服务的基础。

kafka概念

Producer

消息的生产者

Consumer

消息的消费者

Consumer Group

由多个Cousumer组成的一个组,这一个组作为一个Consumer来消费消息,即Consumer Group

Topic

消息的主题,也可以理解为消息的类型,是一个逻辑上的概念,一个Topic内的消息,可以被多个Consumer/Consumer Group订阅,它们将消费这个Topic内的所有消息,特别的,如果订阅Topic的是一个Group,则Group内的Consumer,会分别消费Group内获取的消息,且每个Consumer消费的消息不重复

Partition

消息的分区,在物理上为一个保存了消息的文件,主要是将一个Topic内的消息,分片存储,增加容量的同时提升性能,因为Partition的写入是顺序写入,同时一个Partation在一个Group内只会有一个Consumer消费它

Replica

通过将Partition复制多份存储到kafka集群中不同的实例上来保证消息不丢失,增加容错性

Isr(In-Sync-replica)

kafka通过Isr数量,确保分片副本已经被保存到最小数量的实例上,当Isr总数小于设定值时kafka不允许写入,防止脑裂

Rebalance

规定了一个 Consumer Group 下的所有 Consumer 如何达成一致,来分配订阅 Topic 的每个分区,当kafka发生rebalance会让kafka性能下降,触发rebalance的情况有以下几个

  • 组成员个数发生变化。例如有新的 consumer 实例加入该消费组或者离开组。
  • 订阅的 Topic 个数发生变化。
  • 订阅 Topic 的分区数发生变化。

Ack

生产者端将消息发送至broker后,对生产者做出的响应,分别有3个选项可配置

  • ack=0:异步发送,当生产者发送消息后不再确认是否发送成功
  • ack=1:同步发送,当生产者发送消息后需要收到broker的确认消息才算消息发送成功
  • ack=-1/all:当生产者发送消息后,broker需要将消息写入到集群中最小副本数的节点,才算发送成功

kafka特性

生产者

保证消息不丢失

通过将收到的消息,进行多副本保存,保证消息不丢失

保证消息可靠性

添加事务发送消息,确保事务内的消息发送状态的原子性,以此来保证消息发送的可靠性

保证消息顺序性

使用同步发送消息,同时设置max.in.flight.requests.per.connection=1,确保对于未确认的消息的请求只有一个

消费者

Consumer Group与Partition

顺序消费

broker收到消息之后,根据收到消息的顺序写入partition,同一个partition中,消息的消费是有序的,而多个partition消费则不能保证顺序,业务上如果需要全局有序,需要业务上自行设置标识来保证全局有序

offset

消费者消费到的具体消息位置,kafka的broker中保存了每一个Consumer/Consumer Group的offset,当Consumer消费完消息提交了offset到broker时,在kafka中这条消息才算是被消费了,如果业务上在提交offset过程中出现错误导致提交失败,但消息又已经被消费过,则会产生重复消费消息的问题,因此在业务侧需要做消费幂等

Q.E.D.