kafka

1 kafka架构

1.1 概念和基本架构

kafka介绍


有两种主要的消息传递模式：

1. 点对点传递
2. 发布-订阅模式

kafka就是一种发布订阅模式
对于消息中间件，消息分推拉两种模式。kafka只有消息的拉取，没有推送，可以通过轮询实现消息的推送。

1.1.1 kafka的优势

1.1.2 kafka应用场景

日志收集：一个公司可以用kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种Consumer；
消息系统：解耦生产者和消费者、缓存消息等；
用户活动跟踪：kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后消费者通过订阅这些topic来做实时的监控分析，也可保存到数据库。
运营指标：Kafka也经常⽤来记录运营监控数据。包括收集各种分布式应⽤的数据，⽣产各种操作的集中反馈，⽐如报警和报告；
流式处理：⽐如Spark Streaming和Storm

1.1.3 基本架构

消息和批次
kafka的数据单元称为消息，可以把消息看成是数据库的一个“数据行”。
消息有键，消息由字节数组组成
当消息以一种可控的方式写入不同的分区时，会用到键。
为了提高效率，消息被分批写入kafka。批次就是一组消息，这些消息属于同一个主题和分区。
把消息分成批次可以减少⽹络开销。批次越⼤，单位时间内处理的消息就越多，单个消息的传输时间就越⻓。批次数据会被压缩，这样可以提升数据的传输和存储能⼒，但是需要更多的计算处理。

模式
消息模式（schema）有许多可⽤的选项，以便于理解。如JSON和XML，但是它们缺乏强类型处理能⼒。Kafka的 许多开发者喜欢使⽤Apache Avro。Avro提供了⼀种紧凑的序列化格式，模式和消息体分开。当模式发⽣变化时，不 需要重新⽣成代码，它还⽀持强类型和模式进化，其版本既向前兼容，也向后兼容。

主题和分区

生产者和消费者

broker和集群
⼀个独⽴的Kafka服务器称为broker。broker接收来⾃⽣产者的消息，为消息设置偏移量，并提交消息到磁盘保 存。broker为消费者提供服务，对读取分区的请求做出响应，返回已经提交到磁盘上的消息。单个broker可以轻松处 理数千个分区以及每秒百万级的消息量。
每个集群都有⼀个broker是集群控制器（⾃动从集群的活跃成员中选举出来）。 控制器负责管理⼯作：
1.将分区分配给broker
2.监控broker

集群中⼀个分区属于⼀个broker，该broker称为分区⾸领。
⼀个分区可以分配给多个broker，此时会发⽣分区复制。
分区的复制提供了消息冗余，⾼可⽤。副本分区不负责处理消息的读写。

2 kafka高级特性解析

2.1 主题

2.1.1 管理

创建主题

kafka-topics.sh --zookeeper localhost:2181/myKafka --create --topic topic_x -- partitions 1 --replication-factor 1
kafka-topics.sh --zookeeper localhost:2181/myKafka --create --topic topic_test_02 -- partitions 3 --replication-factor 1 --config max.message.bytes=1048576 --config segment.bytes=10485760

查看主题

kafka-topics.sh --zookeeper localhost:2181/myKafka --list
kafka-topics.sh --zookeeper localhost:2181/myKafka --describe --topic topic_x
kafka-topics.sh --zookeeper localhost:2181/myKafka --topics-with-overrides --describe

修改主题

kafka-topics.sh --zookeeper localhost:2181/myKafka --create --topic topic_test_01 -- partitions 2 --replication-factor 1
kafka-topics.sh --zookeeper localhost:2181/myKafka --alter --topic topic_test_01 -- config max.message.bytes=1048576
kafka-topics.sh --zookeeper localhost:2181/myKafka --describe --topic topic_test_01 kafka-topics.sh --zookeeper localhost:2181/myKafka --alter --topic topic_test_01 -- config segment.bytes=10485760
kafka-topics.sh --zookeeper localhost:2181/myKafka --alter --delete-config max.message.bytes --topic topic_test_01

删除主题

kafka-topics.sh --zookeeper localhost:2181/myKafka --delete --topic topic_x

2.1.2 增加分区

kafka-topics.sh --zookeeper localhost/myKafka --alter --topic myTop1 --partitions 2

2.1.3 分区副本的分配

2.2 分区

2.2.1 副本机制

2.2.2 Leader选举

2.3 稳定性

2.3.1 事务

1、事务使⽤场景
在⼀个原⼦操作中，根据包含的操作类型，可以分为三种情况，前两种情况是事务引⼊的场景，最后⼀种没⽤。

1. 只有Producer⽣产消息；
2. 消费消息和⽣产消息并存，这个是事务场景中最常⽤的情况，就是我们常说的
   模式
3. 只有consumer消费消息，这种操作其实没有什么意义，跟使⽤⼿动提交效果⼀样，⽽且也不是事务属性引 ⼊的⽬的，所以⼀般不会使⽤这种情况

2、事务配置
1、创建消费者代码，需要：
将配置中的⾃动提交属性（auto.commit）进⾏关闭
⽽且在代码⾥⾯也不能使⽤⼿动提交commitSync( )或者commitAsync( ) 设置isolation.level
2、创建⽣成者，代码如下,需要： 配置transactional.id属性
配置enable.idempotence属性

2.3.2 控制器

Kafka集群包含若⼲个broker，broker.id指定broker的编号，编号不要重复。
Kafka集群上创建的主题，包含若⼲个分区。
每个分区包含若⼲个副本，副本因⼦包括了Follower副本和Leader副本。
副本⼜分为ISR（同步副本分区）和OSR（⾮同步副本分区）。

控制器就是⼀个broker。
控制器除了⼀般broker的功能，还负责Leader分区的选举。

2.3.2.1 broker选举

集群⾥第⼀个启动的broker在Zookeeper中创建临时节点 /controller。
其他broker在该控制器节点创建Zookeeper watch对象，使⽤Zookeeper的监听机制接收该节点的变更。

即：Kafka通过Zookeeper的分布式锁特性选举集群控制器。

每个新选出的控制器通过 Zookeeper 的条件递增操作获得⼀个全新的、数值更⼤的 controller epoch。其他 broker 在知道当前 controller epoch 后，如果收到由控制器发出的包含较旧epoch 的消息，就会忽略它们，以防⽌ “脑裂”。

结论：

1. Kafka 使⽤ Zookeeper 的分布式锁选举控制器，并在节点加⼊集群或退出集群时通知控制器。
2. 控制器负责在节点加⼊或离开集群时进⾏分区Leader选举。
3. 控制器使⽤epoch 来避免“脑裂”。“脑裂”是指两个节点同时认为⾃⼰是当前的控制器。

2.3.3 可靠性保证

2.3.3.1 失效副本

Kafka中，⼀个主题可以有多个分区，增强主题的可扩展性，为了保证靠可⽤，可以为每个分区设置副本数。 只有Leader副本可以对外提供读写服务，Follower副本只负责poll Leader副本的数据，与Leader副本保持数据的
同步。
系统维护⼀个ISR副本集合，即所有与Leader副本保持同步的副本列表。 当Leader宕机找不到的时候，就从ISR列表中挑选⼀个分区做Leader。
如果ISR列表中的副本都找不到了，就剩下OSR的副本了。
此时，有两个选择：要么选择OSR的副本做Leader，优点是可以⽴即恢复该分区的服务。 缺点是可能会丢失数据。
要么选择等待，等待ISR列表中的分区副本可⽤，就选择该可⽤ISR分区副本做Leader。优点是不会丢失数据 缺点是会影响当前分区的可⽤性。

2.3.4 ⼀致性保证

2.3.4 消息重复

消息重复主要发⽣在以下三个阶段：

1. ⽣产者阶段
2. broke阶段
3. 消费者阶段

⽣产发送的消息没有收到正确的broke响应，导致producer重试。
producer发出⼀条消息，broke落盘以后因为⽹络等种种原因发送端得到⼀个发送失败的响应或者⽹络中断，然 后producer收到⼀个可恢复的Exception重试消息导致消息重复。