分布式消息中间件-kafka

谁借莪１个温暖的怀抱￠ 2021-10-09 09:40 432阅读 0赞

# Kafka 基础     #

Kafka 是一个分布式的基于发布/订阅模式的消息引擎系统

1.  削峰填谷
2.  应用解耦
3.  异步处理理
4.  高吐出（10-20w的QPS）
5.  高性能

![20210608112322181.png][]

## 架构图  ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70][]

Kafka用zk管理broker

## 搞定术语    ##

生产者：Producer。向主题发布新消息的应用程序。

消费者：Consumer。从主题订阅新消息的应用程序。消息：Record。Kafka是消息引擎嘛，这⾥里里的消息就是指Kafka处理理的主要对象。

主题：Topic。主题是承载消息的逻辑容器器，在实际使用中多用来区分具体的业务。（一个topic只有一个leader 有多个follow）

分区：Partition。一个有序不不变的消息序列列。每个主题下可以有多个分区。（一个Partition只能给一个consumer消费，一个consumer可以消费多个partition）

消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不不变的值。（Offset存在broker里面）

副本：Replica。Kafka中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不不同的⻆角⾊色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。

消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自⼰己的消费者位移。

消费者组：Consumer Group。多个消费者实例例共同组成的一个组，同时消费多个分区以实现高吞吐。重平衡：Rebalance。消费者组内某个消费者实例例挂掉后，其他消费者实例例自动重新分配订阅主题分区的过程。Rebalance是Kafka消费者端实现高可用的重要手段。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 1][]

## 核⼼心参数      ##

*  Broker参数
 *  存储类
 *  log.dirs=/home/kafka1,/home/kafka2,/home/kafka3• ZooKeeper相关 • zookeeper.connect=zk1:2181,zk2:2181,zk3:2181/kafka1
 *  连接类
 *  listeners=CONTROLLER: //localhost:9092
 *   listener.security.protocol.map=CONTROLLER:PLAINTEX 
 *   Topic 管理
 *   auto.create.topics.enable： 不能自立为王
 *  unclean.leader.election.enable： 宁缺毋烂 
 *   auto.leader.rebalance.enable：江山不易改
 *  数据留留存
 *   
 *  log.retention.\{hours|minutes|ms\} ：数据寿命 hours=168 
 *   log.rentention.bytes: 祖宅大⼩小 -1 表示没限
 *  message.max.bytes: 祖宅大⻔门宽度，默认1000012=976KB

**生产消费                                                                                                               **

# kafka特性深入剖析                                                             #

## 日志存储                                                                                                                 ##

Kafka 中的消息是以主题为基本单位进⾏行行归类的，各个主题在逻辑上相互独立。每个主题又可以分为一个或多个分区，分区的数量量可以在主题创建的时候指定，也可以在之后修改。每条消息在发送的时候会根据分区规则被追加到指定的分区中，分区中的每条消息都会被分配一个唯一的序列列号，也就是通常所说的偏移量量（offset）。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 2][]

不不考虑多副本的情况，一个分区对应一个日志（Log）。为了防止 Log 过大，Kafka 又引⼊入了日志分段（LogSegment）的概念，将 Log 切分为多个 LogSegment，相当于一个巨型文件被平均分配为多个相对较⼩小的文件，这样也便便于消息的维护和清理理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 3][]

向主题topic-log中发送一定量量的消息，某一时刻topic-log-0⽬目录中的布局：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 4][]

## 分区副本剖析                                                                                                          ##

Kafka 通过多副本机制实现故障自动转移，在 Kafka 集群中某个 broker 节点失效的情况下仍然保证服务可用。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 5][]

我们该如何确保副本中所有的数据都是一致的呢？特别是对Kafka而⾔言，当生产者发送消息到某个主题后，消息是如何同步到对应的所有副本中的呢？针对这个问题，最常⻅见的解决方案就是采用基于领导者

（Leader-based）的副本机制。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 6][]

第一，副本分成两类：领导者副本（Leader Replica）和追随者副本（Follower Replica）。

（所有的读写都在leader  follow不做读写）

第二，Follower副本是不不对外提供服务的。这就是说，任何一个追随者副本都不不能响应消费者和生产者的读写请求。所有的请求都必须由领导者副本来处理理，或者说，所有的读写请求都必须发往领导者副本所在的Broker，由该Broker负责处理理。

第三，当领导者副本挂掉了，或者说领导者副本所在的Broker宕机时，Kafka依托于ZooKeeper提供的监控功能够实时感知到，并立即开启新一轮的领导者选举，从追随者副本中选一个作为新的领导者。

老Leader副本重启回来后，只能作为追随者副本加⼊入到集群中。

**ISR  AR**

分区中的所有副本统称为 AR，而 ISR 是指与 leader 副本保持同步状态的副本集合，当然 leader 副本本身也是这个集合中的一员。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 7][]

**失效副本**正常情况下，分区的所有副本都处于 ISR 集合中，但是难免会有异常情况发生，从而某些副本被剥离出 ISR 集合中。在 ISR 集合之外，也就是处于同步失效或功能失效（⽐比如副本处于⾮非存活状态）的副本统称为失效副本，失效副本对应的分区也就称为同步失效分区，即 under-replicated 分区。

bin/kafka-topics.sh --zookeeper localhost: 2181/kafka --describe --topic topic-partitions --under-replicated-partitions

\[root@node1 kafka\_2.11-2.0.0\]\# bin/kafka-topics.sh --zookeeper localhost:2181/ kafka --describe --topic topic-partitions --under-replicated-partitions      Topic: topic-partitions  Partition: 0  Leader: 1 Replicas: 1,2,0 Isr: 1,0

Topic: topic-partitions  Partition: 1  Leader: 0 Replicas: 2,0,1 Isr: 0,1

Topic: topic-partitions  Partition: 2  Leader: 0 Replicas: 0,1,2 Isr: 0,1

分析：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 8][]

**LEO与****HW**

LEO 标识每个分区中最后一条消息的下一个位置，分区的每个副本都有自⼰己的 LEO，ISR 中最⼩小的 LEO 即为 HW，俗称高⽔水位，消费者只能拉取到 HW 之前的消息。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 9][]

（副本网络延时，会被踢出isr，避免延时过久）

分析在拉去数据过程中各个副本 LEO 和 HW 的变化情况：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 10][]

## 可靠性ack分析                                                                                                      ##

仅依靠副本数来支撑可靠性是不不够的，大多数人还会想到生产者客户端参数 request.required.acks。

对于 acks = 1 的配置，生产者将消息发送到 leader 副本，leader 副本在成功写⼊入本地日志之后会告知生产者已经成功提交，如下图所示。如果此时 ISR 集合的 follower 副本还没来得及拉取到 leader 中新写⼊入的消息，leader 就宕机了，那么此次发送的消息就会丢失。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 11][]

对于 ack = -1 的配置，生产者将消息发送到 leader 副本，leader 副本在成功写⼊入本地日志之后还要等待 ISR 中的 follower 副本全部同步完成才能够告知生产者已经成功提交，即使此时 leader 副本宕机，消息也不不会丢失。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 12][]

对于 ack = 0 的配置这意味着producer⽆无需等待来自broker的确认而继续发送下一批消息。这种情况下数据传输效率最高，但是数据可靠性确是最低的。

**\#****磁盘顺序读写    ** kafak采用的是磁盘顺序读写方式，极大提升了读写性能。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 13][]

## 高性能页缓存                                                                                                       ##

一般磁盘 I/O 的场景有以下四种：

1.  用户调用标准 C 库进⾏行行 I/O 操作，数据流为：应用程序 buffer→C 库标准 IObuffer→文件系统⻚页缓存→通过具体文件系统到磁盘。
2.  用户调用文件 I/O，数据流为：应用程序 buffer→文件系统⻚页缓存→通过具体文件系统到磁盘。
3.  用户打开文件时使用 O\_DIRECT，绕过⻚页缓存直接读写磁盘。
4.  用户使用类似 dd ⼯工具，并使用 direct 参数，绕过系统 cache与文件系统直接写磁盘。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 14][]

## 零拷贝                                                                                                                     ##

所谓的零拷贝是指将数据直接从磁盘文件复制到网卡设备中，而不不需要经由应用程序之手。零拷贝大大提高了应用程序的性能，减少了内核和用户模式之间的上下文切换。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 15][]

1.  调用 read() 时，文件 A 中的内容被复制到了内核模式下的 Read Buffer 中。
2.  CPU 控制将内核模式数据复制到用户模式下。
3.  调用 write() 时，将用户模式下的内容复制到内核模式下的 Socket Buffer 中。
4.  将内核模式下的 Socket Buffer 的数据复制到网卡设备中传送。

**零拷贝**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 16][]

# 常用命令    #

##  zk  ##

cd /usr/local/Cellar/zookeeper/3.4.10/bin
    
    ./zkServer start
    
    ./zkCli

## kafka   ##

cd /Users/vking/tools/kafka_2.11-1.0.1/bin
    ./kafka-server-start.sh ../config/server.properties
    log /tmp/kafka-logs

### 创建topic   ###

./kafka-topics.sh --create  --zookeeper 127.0.0.1:2181 --replication-factor 1
    --partitions 1 --topic test_

###    查看topic 列表    ###

./kafka-topics.sh --zookeeper  127.0.0.1:2181 --list

### 生产 ###

./kafka-console-producer.sh  --broker-list  127.0.0.1:9092  --topic  test_1

### 消费 ###

./kafka-configs.sh --zookeeper 127.0.0.1:2181 --entity-type brokers --entitydefault --describe
    ./kafka-configs.sh --zookeeper 127.0.0.1:2181 --entity-type brokers --entityname 0 --describe

###    **查看kafka配置   ** ###

## ##

./kafka-configs.sh --zookeeper 127.0.0.1:2181 --entity-type brokers --entitydefault --describe
    ./kafka-configs.sh --zookeeper 127.0.0.1:2181 --entity-type brokers --entityname 0 --describe

[20210608112322181.png]: /images/20211009/3f3e2f3bc0d54ab1b0f3dc9d7a24ef81.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70]: /images/20211009/1c650edb775741c392b9c5d37ce9046b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 1]: /images/20211009/7b06de5e488d401ca309daf5c6555554.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 2]: /images/20211009/a810250dea3a4b1c96cf9520589caf84.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 3]: /images/20211009/14ea439628334697a81f5394259350c3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 4]: /images/20211009/ca391fb774d843a7afe516127920bbff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 5]: /images/20211009/c1fbdcefaf91420386d0a7b8a48e9352.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 6]: /images/20211009/9e1306201276404b87e33a19283a1da7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 7]: /images/20211009/5cfdc79977ad4edeb259922636a16605.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 8]: /images/20211009/2206a01b1fbe4a688315bf0cb4c0dbb7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 9]: /images/20211009/60a7690c3eb74503a8b9ac66637f30c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 10]: /images/20211009/8ccad2cb5ff0478b9206ba3b45a1c2cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 11]: /images/20211009/4315cf5a901643cab633012a9c094147.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 12]: /images/20211009/4add4ccf74e04b57ac8e49c9ef931713.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 13]: /images/20211009/6d103b1b26d241a898c337a0cd01a357.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 14]: /images/20211009/7607f3706bc543d2b8eee51bd8114004.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 15]: /images/20211009/82cf04d4e12b4fd48944de2b810d19f9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzU1ODU4_size_16_color_FFFFFF_t_70 16]: /images/20211009/76f092a192124e1c9afadf1a93c4173d.png