Kafka - 技术栈

文章目录

[1. Kafka简介](#1. Kafka简介)
[2. 分区和副本机制](#2. 分区和副本机制)
- [2.1 生产者分区写入策略](#2.1 生产者分区写入策略)
- [2.2 乱序问题](#2.2 乱序问题)
- [2.3 消费者组Rebalance机制](#2.3 消费者组Rebalance机制)
- [2.4 消费者分区分配策略](#2.4 消费者分区分配策略)
- [2.5 副本的ACK机制](#2.5 副本的ACK机制)
[3. Kafka原理](#3. Kafka原理)
- [3.1 leader和follower](#3.1 leader和follower)
- [3.2 leader选举](#3.2 leader选举)
- [3.3 Kafka读写流程](#3.3 Kafka读写流程)
- [3.4 Kafka的消息不丢失](#3.4 Kafka的消息不丢失)

1. Kafka简介

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

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内的消费者消费的分区分配。
触发时机
- 消费者数量发生变化
  - 某个消费者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：仅被一次消费