5-Kafka中的分区副本机制

轮询（按照消息尽量保证每个分区的负载）策略，消息会均匀地分布到每个partition

写入消息的时候，key为null的时候，默认使用的是轮询策略 随机策略（不使用）按key写入策略，key.hash() % 分区的数量自定义分区策略（类似于MapReduce指定分区）

乱序问题

在Kafka中生产者是有写入策略，如果topic有多个分区，就会将数据分散在不同的partition中存储当partition数量大于1的时候，数据（消息）会打散分布在不同的partition中如果只有一个分区，消息是有序的

再均衡：在某些情况下，消费者组中的消费者消费的分区会产生变化，会导致消费者分配不均匀（例如：有两个消费者消费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就是直接让Kafka帮助管理、处理分配、数据

offset存储在ZK中由kafka的rebalance来控制消费者分配的分区开发起来比较简单，无需开发者关注底层细节无法做到细粒度的控制 低级API：由编写的程序自己控制逻辑

自己来管理Offset，可以将offset存储在ZK、MySQL、Redis、Hbase、Flink的状态存储指定消费者拉取某个分区的数据可以做到细粒度的控制原有的Kafka的策略会失效，需要我们自己来实现消费机制