第四十三章：kafka

1.文档教程

官方文档：
工作流程：https://kafka.apache.org/intro
快速入门：https://kafka.apache.org/quickstart
详细文档：https://kafka.apache.org/documentation/

官方教程：
confluent-kafka-python项目地址：https://github.com/confluentinc/confluent-kafka-python
python文档教程：https://developer.confluent.io/get-started/python/
视频教程：https://developer.confluent.io/courses/kafka-python/intro/

kafka架构地址：https://kafka.apache.org/40/documentation/streams/architecture

2.简介

Kafka 结合了三种关键功能，因此您可以使用经过实战检验的解决方案端到端实现事件流的用例：

发布（写入）和订阅（读取）事件流，包括从其他系统持续导入/导出数据。
按照您需要的时间持久可靠地存储事件流。
在事件流发生时或回顾性地处理它们。

所有这些功能都以分布式、高度可扩展、弹性、容错和安全的方式提供。Kafka 可以部署在裸机硬件、虚拟机和容器上，也可以部署在本地和云中。您可以选择自行管理 Kafka 环境，也可以使用各种供应商提供的完全托管服务。

# 官网：https://kafka.apache.org/documentation/#introduction

我们设计 Kafka 的目的是让它成为一个统一的平台，处理大型公司可能拥有的 所有实时数据。为了实现这一点，我们必须考虑一系列相当广泛的用例。

它必须具有高吞吐量来支持大量事件流，例如实时日志聚合。
它需要妥善处理大量数据积压，以便能够支持来自离线系统的定期数据加载。
这也意味着系统必须处理低延迟传递才能处理更传统的消息传递用例。

我们希望支持对这些数据流进行分区、分布式、实时处理，从而创建新的派生数据流。这催生了我们的分区和消费者模型。

最后，在将流输入到其他数据系统进行服务的情况下，我们知道该系统必须能够在机器故障时保证容错能力。

为了支持这些用途，我们设计了一个包含许多独特元素的系统，它更类似于数据库日志，而非传统的消息系统。我们将在以下章节中概述该设计的一些元素。

3.Docker 启动

Docker是一种流行的容器运行时。基于 JVM 的 Apache Kafka 的 Docker 镜像可以在 Docker Hub 上找到，从 3.7.0 版本开始可用。

# 获取镜像
docker pull apache/kafka:4.0.0
docker pull apache/kafka:latest

# 启动容器
docker run -p 9092:9092 apache/kafka:4.0.0

使用 docker-compose 启动容器

version: '3.9'
services:
  zookeeper:
    image: 'bitnami/zookeeper:3.7.2'
    container_name: zookeeper
    environment:
      - ALLOW_ANONYMOUS_LOGIN=yes
      - TZ=Asia/Shanghai
  
  kafka:
    image: 'bitnami/kafka:3.2.3'
    container_name: kafka
    user: root
    ports:
      - '9492:9092'
    environment:
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092
      # 客户端连接 Kafka 代理时所使用的地址和端口
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://127.0.0.1:9492
      - KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181
      - KAFKA_CFG_MESSAGE_MAX_BYTES=10485760
      - KAFKA_CFG_REPLICA_FETCH_MAX_BYTES=10485760
      - ALLOW_PLAINTEXT_LISTENER=yes
      - TZ=Asia/Shanghai
    volumes:
      - ./kafka/data:/bitnami/kafka/data
    depends_on:
      - zookeeper
  
  kafka-ui:
    container_name: kafka-ui
    image: provectuslabs/kafka-ui:latest
    ports:
      - '9490:8080'
    environment:
      - DYNAMIC_CONFIG_ENABLED=true
      - KAFKA_CLUSTERS_0_NAME=local_kafka
      - KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=kafka:9092
      - TZ=Asia/Shanghai
    depends_on:
      - kafka

4.术语解释

### 1.broker
Kafka 集群包含一个或多个服务器，服务器节点称为broker。

broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。

如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。

如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

### 2.Topic
类似于数据库的表名
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

### 3.Partition
topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

### 4.Producer
生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息**追加**到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

### 5.Consumer
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

### 6.Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制-给consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。

### 7.Leader
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

### 8.Follower
Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

### 9.Offset
kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

5.主题参数

# 分区数（Partitions） 3-5个
1.并发性：更多的分区可以提高并发消费能力，因为多个消费者可以同时读取不同的分区
2.分区数可以超过 Broker 数量，每个 Broker 可托管多个分区的领导者或副本
3.分区数 ≈ 预期峰值吞吐量 / 单个分区的吞吐量 

# 复制因子（Replication Factor） 官网推荐：3个
1.更高的复制因子可以提高数据的可靠性和可用性，以确保高可用性和容错能力
2.若复制因子为 3，则至少需要 3 个 Broker
3.最小集群规模应满足 复制因子 ≤ Broker 数量

# 最小同步副本数（Min In-Sync Replicas） 2个
1.最小同步副本数是指在写入操作成功前，至少需要有多少个副本副本处于同步状态。设置较高的值可以确保数据在写入时的一致性，防止数据丢失
2.复制因子=3，min.insync.replicas=2 时：
  正常情况下，消息需写入至少 2 个同步副本（包括 Leader 副本），生产者才会收到成功确认。
  若同步副本数降至 1（例如 2 个副本宕机），生产者将无法写入消息，直到同步副本恢复至 ≥2。

6.生产者与消费者

# python 编程，见utils ---> async_kafka_driver.py
getee：https://gitee.com/ysging/mqtt_django.git

posted @ 2025-04-17 14:40 亦双弓阅读(53) 评论(0) 收藏举报

刷新页面返回顶部

亦双弓