kafka 基础

消息生产者

采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘

Producer

Kafka服务器，负责消息存储和转发，一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

Borker

消息消费者

Consumer

保存着集群broker、topic、partition等meta数据

负责broker 故障发现，partition leader选举，负载均衡等功能

Zookeeper

角色

消息逻辑分组类别，Kafka按照topic来分类消息

Topic

topic的物理分区，一个 topic 可以包含多个 partition，topic消息保存在各个 partition上

实现扩展性，一个partition是一个有序的队列

Partition

Kafka采取了分片和索引机制，将每个partition分为多个segment

每个segment对应两个文件(*.index表示存放数据的索引，*.log表示存储的数据)

数据默认存储7天。其中的每一个消息都被赋予了一个唯一的offset值

segment

消息在日志中的位置，可以理解是消息在 partition上的偏移量，也是代表该消息的唯一序号

Offset

消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

Consumer Group

partition 的副本，保障 partition 的高可用（的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作）

一个topic的每个分区都有若干个副本，一个leader和若干个follower

Replica

replica 中的一个角色，每个分区多个副本的主， producer消费数据的对象 consumer发送数据的对象只跟 leader 交互

Leader

replica 中的一个角色，每个分区多个副本中的从，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的follower

不和producer消费数据的对象 consumer发送数据的对象，不做数据读写

Follower

kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover

Controller

消息，通信的基本单位，每个producer可以向一个topic发布一些消息

Message

概念

架构

没有指定分区编号，没有指定key时采用轮询方式存储数据

没有指定分区编号，指定key时，数据分发策略为对key求取hash值，这个值与分区数量取余，余数就是分区编号

指定分区编号，所有数据输入到指定的分区内

自定义分区

生产数据到分区方式

生产者

consumer采用pull模式从broker中读取数据

消费方式

范围分区RangeAssignor

轮询分区RoundRobinAssignor

粘性分区StickyAssignor

分区分配策略

一个消费者可以消费多个分区

一个分区只能被一个消费者消费

同一个消费者组内

1、首先Consumer连接指定的Topic partition所在leader broker，使用折半/二分查找，先确定数据所在的segment

2、确定在哪个segment后，使用确定的segment内的index文件找到数据具体的位置采用pull方式从kafkalogs中获取消息

消费数据的流程

消费者

分布式的并发读写数据

分布式

producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写

顺序写磁盘

零拷贝技术

高效读写数据

Kafka集群中有一个broker会被选举为Controller

负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作

Controller的管理工作都是依赖于Zookeeper的

选举过程

Zookeeper作用

单topic 单partition 单消费者

单topic 指定相同message key 已保证同 key 的消息能路由到相同的 partition 单消费者

顺序消费

是⼀个分布式、⽀持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统

简介

高吞吐量、低延迟

kafka集群支持热扩展

可扩展性

消息被持久化掉本地磁盘，并且支持数据备份防止数据丢失

持久性、可靠性

容错性

支持数千个客户端同时读写

高并发

特征

一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等

日志收集

解耦和⽣产者和消费者、缓存消息等

消息系统

Kafka经常被⽤来记录web⽤户或者app⽤户的各种活动，如浏览⽹⻚、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘

⽤户活动跟踪

Kafka也经常⽤来记录运营监控数据。包括收集各种分布式应⽤的数据，⽣产各种操作的集中反馈，⽐如报警和报告。

运营指标

比如spark streaming和storm

流式处理

适用场景

可靠性强（分布式-分区-副本）、扩展性强（可伸缩）、性能高（数据读写）、耐用性强（数据持久化）、时效性强。

优点

由于是批量发送，数据并非真正的实时。

仅支持统一分区内消息有序，无法实现全局消息有序

有可能消息重复消费

依赖zookeeper进行元数据管理

缺点

介绍

选举新的leader时，容忍n台节点的故障，需要n+1个副本

延迟高

全部完成同步，才发送ack

副本数据同步方案

网络延迟对Kafka的影响较小

方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，减少冗余

原因

数据可靠性

动态的in-sync replica (ISR) set，意为和leader保持同步的follower集合

当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。

如果follower长时间未向leader同步数据，则该follower将被踢出ISR

ISR

每个副本最大的offset

LEO

消费者能见到的最大的offset，ISR队列中最小的LEO

HW

follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了

follower故障

leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据

leader故障

故障处理

副本同步

producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；

acks= 0

producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；认为leader返回 信息就成功了

acks = 1

producer等待broker的ack，partition的leader和follower(ISR中的)全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。leader收到信息了返回ok，follower收到信息但是发送ACK时候leader故障，此时生产者会重新给follower发送个信息

acks = -1 或 acks = all

ACK 应答机制

时间：默认存储168小时（一周）

数据的大小：默认 -1 （不删除），可以自行设置

数据删除机制

broker

设置ack = all 或者 ack = -1

同步发送消息

设置retries重试次数

手动提交：enable.auto.commit=false

副本数大于等于3，replication.factor >= 3

min.insync.replicas>1

确保 replication.factor > min.insync.replicas

Broker

消息可靠性

kafka基础