2. 分区和副本机制
2.1 生产者分区写入策略
生产者写入消息到topic，Kafka将依据不同的策略将数据分配到不同的分区中
轮询分区策略- 随机分区策略
按key分区分配策略：按key分配策略，有可能会出现「数据倾斜」，例如：某个key包含了大量的数据，因为key值一样，所有所有的数据将都分配到一个分区中，造成该分区的消息数量远大于其他的分区。- 自定义分区策略
2.2 乱序问题
乱序问题
在Kafka中生产者是有写入策略（轮询），如果topic有多个分区，就会将数据分散在不同的partition中存储，当partition数量大于1的时候，数据（消息）会打散分布在不同的partition中，如果只有一个分区，消息是有序的
2.3 消费者组Rebalance机制
- 再均衡：在某些情况下，消费者组中的消费者消费的分区会产生变化，会导致消费者分配不均匀，Kafka Consumer Group就会启用rebalance机制，重新平衡这个Consumer Group内的消费者消费的分区分配。
- 触发时机
消费者数量发生变化
topic的数量发生变化
partition的数量发生变化
- 不良影响
- 发生rebalance，所有的consumer将不再工作，共同来参与再均衡，直到每个消费者都已经被成功分配所需要消费的分区为止（rebalance结束）
2.4 消费者分区分配策略
分区分配策略：保障每个消费者尽量能够均衡地消费分区的数据，不能出现某个消费者消费分区的数量特别多，某个消费者消费的分区特别少
- Range分配策略（范围分配策略）：Kafka默认的分配策略
- n：分区的数量 / 消费者数量
- m：分区的数量 % 消费者数量
- 前m个消费者消费n+1个分区
- 剩余的消费者消费n个分区
- RoundRobin分配策略（轮询分配策略）
- Striky粘性分配策略
- 在没有发生rebalance跟轮询分配策略是一致的
- 发生了rebalance，轮询分配策略，重新走一遍轮询分配的过程。而粘性会保证跟上一次的尽量一致，只是将新的需要分配的分区，均匀的分配到现有可用的消费者中即可
- 减少上下文的切换
2.5 副本的ACK机制
口述：：：要往某个Topic中写数据，Topic包含很多个分区，每个broker就先当于一个服务器，存储一个分区的leader，在其他的broker中存储分区的副本，目的就是当分区的leader挂了后，选举副本为leader，这样这个分区信息就不会丢失了，客户端访问的都是分区的leader，lader提供读写的功能，follower（也就是分区的副本）不提供读写功能，只作为副本存在，就是防止leader挂了，自己可以顶上去
副本的目的就是冗余备份，当某个Broker（就是服务器）上的分区数据丢失时，依然可以保障数据可用。因为在其他的Broker上的副本是可用的。
- acks = 0：生产者只管写入，不管是否写入成功，可能会数据丢失。性能是最好的
- acks = 1：生产者会等到leader分区写入成功后，返回成功，接着发送下一条
，注意：此时follower还没有备份 - acks = -1/all：确保消息写入到leader分区、还确保消息写入到对应副本都成功后，接着发送下一条，性能是最差的
3. Kafka原理
3.1 leader和follower
- Kafka中的leader和follower是相对分区有意义，不是相对broker
- Kafka在创建topic的时候，会尽量分配分区的leader在不同的broker中，其实就是负载均衡
- leader职责：读写数据
- follower职责：同步数据、参与选举（leader crash之后，会选举一个follower重新成为分区的leader
- 注意和ZooKeeper区分
- ZK的leader负责读、写，follower可以读取
- Kafka的leader负责读写、follower不能读写数据（
确保每个消费者消费的数据是一致的），Kafka一个topic有多个分区leader，一样可以实现数据操作的负载均衡
3.2 leader选举
口述：如果分区的leader挂了，controller（可以理解为master，管理broker的，）会负责分区leader的选举，controller读取到当前分区的ISR，ISR就表示当前有几个follower是存活的，然后选择一个作为分区的leader，这样的话这个分区就能提供读写服务了，因为只有leader才能读写。
- 在Kafka集群启动的时候，每个
broker都会尝试去ZooKeeper上注册成为Controller，但只有一个竞争成功，其他的broker会注册该节点的监视器 - Controller是通过ZK来进行选举的，controller决定分区leader的选举，通过
ISR来进行快速选举
3.3 Kafka读写流程
- 写流程
- 通过ZooKeeper找partition对应的leader，leader是负责写的
- producer开始写入数据
- ISR里面的follower开始同步数据，并返回给leader ACK
- 返回给producer ACK
- 读流程
- 通过ZooKeeper找partition对应的leader，leader是负责读的
- 通过ZooKeeper找到消费者对应的offset
- 然后开始从offset往后顺序拉取数据
- 提交offset（自动提交——每隔多少秒提交一次offset、手动提交——放入到事务中提交）
3.4 Kafka的消息不丢失
- broker消息不丢失：因为有副本relicas的存在，会不断地从leader中同步副本，所以，一个broker crash，不会导致数据丢失，除非是只有一个副本。
- 生产者消息不丢失：ACK机制（配置成ALL/-1）、配置0或者1有可能会存在丢失
- 消费者消费不丢失：重点控制offset（）：保证offset的可靠性，只有成功消费了消息才跟新zookper中的offset。
- At-least once：一种数据可能会重复消费
- Exactly-Once：仅被一次消费