生产者的分区写入策略
- 轮询(按照消息尽量保证每个分区的负载)策略,消息会均匀地分布到每个partition
- 写入消息的时候,key为null的时候,默认使用的是轮询策略
- 随机策略(不使用)
- 按key写入策略,key.hash() % 分区的数量
- 自定义分区策略(类似于MapReduce指定分区)
乱序问题
- 在Kafka中生产者是有写入策略,如果topic有多个分区,就会将数据分散在不同的partition中存储
- 当partition数量大于1的时候,数据(消息)会打散分布在不同的partition中
- 如果只有一个分区,消息是有序的
消费组Consumer Group Rebalance机制
- 再均衡:在某些情况下,消费者组中的消费者消费的分区会产生变化,会导致消费者分配不均匀(例如:有两个消费者消费3个,因为某个partition崩溃了,还有一个消费者当前没有分区要削峰),Kafka Consumer Group就会启用rebalance机制,重新平衡这个Consumer Group内的消费者消费的分区分配。
- 触发时机
- 消费者数量发生变化
- 某个消费者crash
- 新增消费者
- topic的数量发生变化
- 某个topic被删除
- partition的数量发生变化
- 删除partition
- 新增partition
- 不良影响
- 发生rebalance,所有的consumer将不再工作,共同来参与再均衡,直到每个消费者都已经被成功分配所需要消费的分区为止(rebalance结束)
消费者的分区分配策略
分区分配策略:保障每个消费者尽量能够均衡地消费分区的数据,不能出现某个消费者消费分区的数量特别多,某个消费者消费的分区特别少
- Range分配策略(范围分配策略):Kafka默认的分配策略
- n:分区的数量 / 消费者数量
- m:分区的数量 % 消费者数量
- 前m个消费者消费n+1个分区
- 剩余的消费者消费n个分区
- RoundRobin分配策略(轮询分配策略)
- 消费者挨个分配消费的分区
- Striky粘性分配策略
- 在没有发生rebalance跟轮询分配策略是一致的
- 发生了rebalance,轮询分配策略,重新走一遍轮询分配的过程。而粘性会保证跟上一次的尽量一致,只是将新的需要分配的分区,均匀的分配到现有可用的消费者中即可
- 减少上下文的切换
副本的ACK机制
producer是不断地往Kafka中写入数据,写入数据会有一个返回结果,表示是否写入成功。这里对应有一个ACKs的配置。
- acks = 0:生产者只管写入,不管是否写入成功,可能会数据丢失。性能是最好的
- acks = 1:生产者会等到leader分区写入成功后,返回成功,接着发送下一条
- acks = -1/all:确保消息写入到leader分区、还确保消息写入到对应副本都成功后,接着发送下一条,性能是最差的
根据业务情况来选择ack机制,是要求性能最高,一部分数据丢失影响不大,可以选择0/1。如果要求数据一定不能丢失,就得配置为-1/all。
分区中是有leader和follower的概念,为了确保消费者消费的数据是一致的,只能从分区leader去读写消息,follower做的事情就是同步数据,Backup。
高级API(High-Level API)、低级API(Low-Level API)
- 高级API就是直接让Kafka帮助管理、处理分配、数据
- offset存储在ZK中
- 由kafka的rebalance来控制消费者分配的分区
- 开发起来比较简单,无需开发者关注底层细节
- 无法做到细粒度的控制
- 低级API:由编写的程序自己控制逻辑
- 自己来管理Offset,可以将offset存储在ZK、MySQL、Redis、HBase、Flink的状态存储
- 指定消费者拉取某个分区的数据
- 可以做到细粒度的控制
- 原有的Kafka的策略会失效,需要我们自己来实现消费机制