Kafka

1. Kafka简介

• 异步处理
• 系统解耦
• 流量削峰
• 日志处理

2. 分区和副本机制

2.1 生产者分区写入策略

生产者写入消息到topic，Kafka将依据不同的策略将数据分配到不同的分区中

1. 轮询分区策略
2. 随机分区策略
3. 按key分区分配策略：按key分配策略，有可能会出现「数据倾斜」，例如：某个key包含了大量的数据，因为key值一样，所有所有的数据将都分配到一个分区中，造成该分区的消息数量远大于其他的分区。
4. 自定义分区策略

2.2 乱序问题

乱序问题

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

2.3 消费者组Rebalance机制

• 再均衡：在某些情况下，消费者组中的消费者消费的分区会产生变化，会导致消费者分配不均匀，Kafka Consumer Group就会启用rebalance机制，重新平衡这个Consumer Group内的消费者消费的分区分配。
• 触发时机
  • 消费者数量发生变化
    • 某个消费者crash
    • 新增消费者
  • topic的数量发生变化
    • 某个topic被删除
  • partition的数量发生变化
    • 删除partition
    • 新增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：仅被一次消费