Kafka基础

Kafka

Kafka是一个分布式消息系统，由linkedin使用scala编写，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。

阿里巴巴的Metal,RocketMQ都有Kafka的影子，他们要么改造了Kafka或者借鉴了Kafka，最后Kafka的动态扩容是通过Zookeeper来实现的。 

 

Zookeeper是一种在分布式系统中被广泛用来作为：分布式状态管理、分布式协调管理、分布式配置管理、和分布式锁服务的集群。kafka增加和减少服务器都会在Zookeeper节点上触发相应的事件kafka系统会捕获这些事件，进行新一轮的负载均衡，客户端也会捕获这些事件来进行新一轮的处理。

Kafka相关概念

1、 AMQP协议

Advanced Message Queuing Protocol （高级消息队列协议）

The Advanced Message Queuing Protocol (AMQP)： 是一个标准开放的应用层的消息中间件（Message Oriented Middleware）协议。AMQP定义了通过网络发送的字节流的数据格式。因此兼容性非常好，任何实现AMQP协议的程序都可以和与AMQP协议兼容的其他程序交互，可以很容易做到跨语言，跨平台。

基本的概念

消费者（Consumer）：从消息队列中请求消息的客户端应用程序

生产者（Producer）  ：向broker发布消息的应用程序

代理（Broker）：用来接收生产者发送的消息并将这些消息路由给服务器中的队列，便于fafka将生产者发送的消息，动态的添加到磁盘并给每一条消息一个偏移量，所以对于kafka一个broker就是一个应用程序的实例，kafka支持的客户端语言：Kafka客户端支持当前大部分主流语言，包括：C、C++、Erlang、Java、.net、perl、PHP、Python、Ruby、Go、

主题（Topic）：一个主题类似新闻中的体育、娱乐、教育等分类概念，在实际工程中通常一个业务一个主题。

分区（Partition）：Partition 是 Kafka 中比较特色的部分，一个 Topic 可以分为多个Partition，每个 Partition 是一个有序的队列，Partition 中的每条消息都存在一个有序的偏移量（Offest） ，同一个 Consumer Group 中，只有一个 Consumer 实例可消费某个 Partition 的消息。partion可以看作一个有序的队列，里面的数据是储存在硬盘中的，追加式的。partition的作用就是提供分布式的扩展，一个topic可以有许多partions，多个partition可以并行处理数据，所以可以处理相当量的数据。只有partition的leader才会进行读写操作，folower仅作为数据冗余备份，客户端是感知不到的。

副本同步队列 ISR(in-sync replicas)：leader会追踪和维护ISR中所有follower的滞后状态。如果滞后太多（时间滞后replica.lag.time.max.ms可配置），leader会把该replica从ISR中移除。被移除ISR的replica一直在追赶leader。如下图，leader写入数据后并不会commit，只有ISR列表中的所有folower同步之后才会commit，把滞后的follower移除ISR主要是避免写消息延迟。设置ISR主要是为了broker宕掉之后，重新选举partition的leader从ISR列表中选择。

消费组（comsumer group）：如交警项目的putter和sender，属于不同的两个组。每个组包含多个consumer，每条消息只能被组中的一个consumer消费，

偏移量（offest）：偏移量用来在分区中唯一标识这个消息。在不同的分片中可重复。偏移量存储在分区中，但是消费者也会存储一份消费的分区的偏移量，消费者消费后会提交新偏移量给分区（消费者修改偏移量），消费者组新增消费者需要对分组进行再均衡，新增消费者负责的分区偏移量从分区拿，这时候旧消费者还未提交新的偏移量，导致新增消费者重复消费。

副本（Replication）：为保证集群中某个节点发送故障时，该节点上的Partition数据不丢失，而进行备份。一个Topic的每个Partition都有若干副本，一个Leader和若干个Follower，Leader只有一个，负责消息的读写，即所有读写操作只能发生在Leader副本上。Follower有多个，实时从Leader同步数据。当Leader发生故障时，某个Follower会成为新的Leader。备份数量不能多过borker数量

Segment：一个Topic可以分为若干个Partition，Partition还可以细分为segment，一个Partition物理上由多个segment组成，每个segment有.log和.index两个文件，每个log文件承载详细的数据，每条消息都有一个Offset，index文件是对log文件的索引。Consumer查找offset时运用二分法依据文件名去定位到哪个Segment，然后解析Message，匹配到对应的offset的Message

 

 

 

前20位数字代表offset偏移量，

 

中央控制器（Controller）：多个Broker中，有一个会被选举为Controller，管理整个集群的分区和监控副本的状态

 

 

 

 

 

什么是分区和副本

举个例子，broker还是3个。
topic是逻辑概念，比如你有100条消息，topic命名为“A”，A有2个分区PA和PB，也就是说PA存50条，PB存50条，分别在broker1和broker2上面，这样你的消息是不是打散了，不会单一的放在某一台机器上了，这样是不是单一机器的负载就变小了？

再来，如果broker1挂了，那上面的所有分区也挂了，你的50条消息就丢了。为了不丢消息，你为分区增加了副本，这样PA和PB在broker2和broker3分别同步50条消息，当broker1再挂了，分区leader切到broker3上面的副本分区，消息是不是就还在。

所以，分区来打散你的消息，让你把庞大的消息负载均衡到broker之间，副本分区来同步消息来保障你的可靠性。

topic,broker,partition之间的关系

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

leader选举规则

• 开始时leader随机选择
• 当现在的leader挂掉后，假如存在两个follwer
• 哪个follwer与之前leader的同步的及时（偏移量），选举哪一个为leader

消费者组

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

分区

作用

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

数据存放分区确定原则

消息在发送给broker之前就能够确定好发送给哪个分区，批量发送除外，生产者还有个本地缓存，缓存消息，可以设置发送消息缓不缓存，缓存大小超过XXK就发送一次，缓存时间每个XXms就发送一次

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机制

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

存储

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

存储策略

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

 

Kafka优点：

• 基于磁盘的数据存储
• 高伸缩性
• 高性能

Kafka缺点：

• 运维难度大
• 对zk的高度依赖
• 多副本模式对带宽有依赖

 

kafka使用与部署：https://blog.csdn.net/MoastAll/article/details/119577088