kafka基本概念详解

kakfa

消息队列

为什么要使用消息队列

• 通常的消息传输，生产者和消费者之间需要同步，如果一方存在问题那么数据传输就无法进行
• 将消息队列作为缓冲，缓存数据
• 优点：

1. 解耦。将生产者和数据队列分开处理
2. 支持扩展。
3. 灵活，可以随着业务的增加增加机器扩大处理能力
4. 可恢复，数据生产后可以存储在消息队列中
5. 顺序保证，队列先进先出
6. 作为缓冲独立出来，减小生产者的压力
7. 异步通信。生产者和消费者其中一方出现问题不影响另外一方处理

消息队列的两种实现模式

• 点对点模式
  生产者生产后放到队列中，消费者主动从队列中进行拉取
  缺点： 需要实时监控
  kafka属于点对点
• 发布订阅模式
  生产者生产数据根据不同的topic放到队列，消费者在队列中进行注册，确定需要的topic类型，当队列中存在数据时，推送给消费者，消费者被动获取
  缺点：可能丢失数据

Kafka是一个分布式的、可分区的、可复制的消息系统。

客户端和服务端通过TCP协议通信。

zookeeper在kafka的作用：

无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息

概念详解：

• topic：kafka以topic作为单位进行归纳。可以理解为一个队列。
• broker：kafka以集群方式运行，每个节点叫做一个borker，就是一个服务器
• producer：生产消息，把消息放入topic
• consumer：消费消息，从topic中取出消息
• comsumer group：消费组，如交警项目的putter和sender，属于不同的两个组。每个组包含多个consumer，每条消息只能被组中的一个consumer消费，
• partition: 分区数据实际发送的位置
• offest：偏移量用来在分区中唯一标识这个消息。在不同的分片中可重复。
• leader：实际指的是分区，属于topic，每一个分区有自己leader和follwer。如0分区自己是leader,1分区是0分区的follwer，然后1分区自己又是leader，2分区是1的follwer
• follwer: 备份leader的数据，同一分区的leader和follwer不在同一个broker上。
• 备份数量不能多过borker数量

topic,broker,partition之间的关系

1. topic和broker没有直接关系，topic一个抽象概念，broker一个是物理概念
2. 一个topic可以包含多个partition
3. 一个partition只能属于一个topic
4. 一个broker可以存放多个partition的数据，这多个分片可以属于不同的topic
5. 生产者生产的数据发送到topic，实际的存储是在partition，而partition是以broker为载体的。

leader选举规则

• 开始时leader随机选择
• 当现在的leader挂掉后，加入存在两个follwer
• 哪个follwer与之前leader的同步的及时，选举哪一个为leader

消费者组

0. 一个消费者可以消费多个分区
1. 同一个消费组里的消费者，只能同时有一个消费者来消费某个topic的某分片
2. 同一个消费组里的消费者，可以同时消费同一个topic的不同的分片
3. group1组里的consumerA在消费Xtopic0分区的同时，1组里的consumerB可以消费xtopci1分区的数据，不能消费0分区的数据。

分区

作用

• 降低borker的负载，同一个topic的消息可以存到多个borker中
• 提高并发，多个消费者可以同时消费不同分区上的数据

数据存放分区确定原则

1. 生成者直接指定分区
2. 不指定分区但是指定了key，根据key的value进行hash一个分区
3. 都不指定，轮询出一个分区

事务级别

1. 最多一次：消息不会重复发送，最多传输一次，也可能一次也不传输
2. 最少一次：消息不会被漏发，最少传输一次，也可能重复发送
3. 精确一次：不会漏传也不会重复发送，有且只有一次被传输

工作流程

生产

1. 生产者推数据，追加到分区，数据顺序写入磁盘（效率比随机写要高，保障吞吐率）
2. 多个分区，每个分区区内有序，从0开始追加offest

写入步骤（ack为all时）

1. producer和kafka集群交互，获得要存放的分区的leader信息
2. producer和kafka集群交互和leader交互，发送数据
3. leader将数据写入本地磁盘（数据存储目录）
4. follwer从leader主动拉取（pull）数据
5. follwer写入本地后向leader返回ack
6. leader收到所有follwer的ack后，向producer返回ack
7. 数据发送完成

ack机制

1. 0: 不需要确定leader是否收到数据，速度快，稳定性差数据没有保障
2. 1：需要leader确定是否收到数据。不能保证folwer是否能接收的到数据
3. all：需要leader和follwer都确定已经收到数据，效率慢，能够保证数据不丢失

存储

• 实际存储位置
  数据存储目录下的分片文件夹中的.log文件

存储策略

• 消息不是在消费完之后就会立即删除，当超过时间或者大小后才会从offest小的开始清理。
• 通过配置时间和大小来持久化所有消息
  log.retention.bytes：最多保留的文件字节大小，默认为-1
  log.retention.hours：最多保留的时间，小时。优先级最低。默认168。

zookeeper存储信息

broker
consumer

消费

API

• 高级API

1. 代码简单
2. 不需要自行管理offest，系统交给zookeeper来管理
3. 不需要管理分区，副本等。系统自动管理

• 低级API

1. 代码相对复杂
2. 需要自行控制offest
3. 自行控制分区
4. 自行获取分组leader

kafka的消费者{BatchConsumer}在创建时，规定了消费者名称，topic信息，分片列表。

从kafka中批量获取的信息，类型是一个KafkaMessage的list
KafkaMessage中存在三个变量

1. byte[]，message，字节数组类型的消息
2. long，offest，long类型的偏移量
3. int，partition，int类型的分片信息

每个消费者维护自己的offest，这些信息存放在zookeeper中。
在kafka进行测试时可以将该信息存放在本地（高版本）