Kafka（一）利用Docker Compose安装单机Kafka以及Kafka UI

Kafka中涉及到的术语

对于Kafka中经常用到的术语，可参考confluent的官方文档，这里不再赘述。
Kafka镜像选择

Kafka官方镜像

2024-05-14更新：官方在3.7.0中引入了官方Docker镜像，详细利用和例子请参考官方文档 > Docker部门.
由于写文章的时候还没有官方镜像，文章剩余内容均针对的是Docker Hub社区镜像
Docker Hub社区镜像

镜像选择Docker Hub上利用最多的bitnami Kafka，重要注意的点是情况变量和Kafka配置的映射关系
   Additionally, any environment variable beginning with KAFKA_CFG_ will be mapped to its corresponding Apache Kafka key. For example, use KAFKA_CFG_BACKGROUND_THREADS in order to set background.threads or KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE in order to configure auto.create.topics.enable
  另有就是，当利用任何来自于bitnami的镜像，如何遇到了题目，想查察日志，可以将镜像的Debug日志打开，通过情况变量

1. BITNAMI_DEBUG=true

复制代码

控制
由于Docker Hub的说明字数限定，可以在Github上查察完整文档
Kafka UI镜像选择

对于Kafka的UI工具，没有仔细观察，缘故起因是在利用初期阶段，还不知道对于Kafka的监控和管理的痛点在哪，以是先用起来再说。
Kafka UI官方Github地址 > 文档网址 > Compose examples 下面可以找打很多Kafak ui的compose文件示例，不仅对UI的配置很有帮助，而且对刚入门Kafka的同学，也提供了非常好的示例，包括Kraft模式的Kafka集群等。
其他配置则阅读官方文档即可。
Docker Compose文件

1. version: "3"
2. services:
3.   kafka:
4.     image: 'bitnami/kafka:latest'
5.     container_name: kafka
6.     ports:
7.       - "9092:9092"
8.       - "9093:9093"
9.       - "9998:9998"
10.     volumes:
11.       - type: volume
12.         source: kafka_standalone_data
13.         target: /bitnami/kafka
14.         read_only: false
15.     environment:
16.       - BITNAMI_DEBUG=yes
17.       # 启用KRaft模式必须设置下面三个属性
18.       - KAFKA_CFG_NODE_ID=1
19.       - KAFKA_CFG_PROCESS_ROLES=broker,controller
20.       - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
21.       # broker id
22.       - KAFKA_BROKER_ID=1
23.       # listener的各种配置
24.       - KAFKA_CFG_LISTENERS=CONTROLLER://:9094,BROKER://:9092,EXTERNAL://:9093
25.       - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,BROKER:PLAINTEXT,EXTERNAL:PLAINTEXT
26.       # 注意EXTERNAL配置的是当前Docker所在的主机地址,BROKER可以使用Docker内部的网络地址即可
27.       - KAFKA_CFG_ADVERTISED_LISTENERS=BROKER://kafka:9092,EXTERNAL://192.168.0.101:9093
28.       # 内部各个broker之间通信用的listener
29.       - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=BROKER
30.       # 用来进行选举的Controller服务器，如果有多个Controller则都需要写上，这里本机
31.       - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@127.0.0.1:9094
32.       - ALLOW_PLAINTEXT_LISTENER=yes
33.       # 开启JMX监控
34.       - JMX_PORT=9998
35.       - KAFKA_JMX_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=kafka -Dcom.sun.management.jmxremote.rmi.port=9998
36.   kafka-ui:
37.     container_name: kafka-ui
38.     image: provectuslabs/kafka-ui:latest
39.     ports:
40.       - "9095:8080"
41.     depends_on:
42.       - kafka
43.     environment:
44.       KAFKA_CLUSTERS_0_NAME: kafka-stand-alone
45.       KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka:9092
46.       KAFKA_CLUSTERS_0_METRICS_PORT: 9998
47.       SERVER_SERVLET_CONTEXT_PATH: /kafkaui
48.       AUTH_TYPE: "LOGIN_FORM"
49.       SPRING_SECURITY_USER_NAME: admin
50.       SPRING_SECURITY_USER_PASSWORD: kafkauipassword
51.       DYNAMIC_CONFIG_ENABLED: 'true'
52. volumes:
53.   kafka_standalone_data:
54.     driver: local

复制代码

Kafka配置项说明

KRaft vs Zookeeper

这里我们的配置是选择的是KRaft，因为Kafka官方已经筹划在Kafak中移除Zookeeper。至于为什么要移除？confluentinc官方写了很多文章，这里不再逐一列举，在Google上一搜就一大堆

1. KRaft site:confluent.io

复制代码

下面是几篇文章

• why move to kraft
  
• Why ZooKeeper Was Replaced with KRaft
  
• Apache Kafka Without ZooKeeper
  
• Getting Started with the KRaft Protocol
  

和KRaft有关的配置

• node.id       The node ID associated with the roles this process is playing when process.roles is non-empty. This is required configuration when running in KRaft mode.
  
• porcess.roles       The roles that this process plays: ‘broker’, ‘controller’, or ‘broker,controller’ if it is both. This configuration is only applicable for clusters in KRaft (Kafka Raft) mode (instead of ZooKeeper). Leave this config undefined or empty for Zookeeper clusters
  
• controller.listener.names       A comma-separated list of the names of the listeners used by the controller. This is required if running in KRaft mode
  

关于Controller和Broker的概念解释

一句话解释：
Controller负责协调Broker（详细解释可见Kafak权威指南的第5章，该书可在Apache Kafak官网 > Get Started > Books 中找到免费下载）
   To summarize, Kafka uses Zookeeper’s ephemeral node feature to elect a controller
and to notify the controller when nodes join and leave the cluster. The controller is
responsible for electing leaders among the partitions and replicas whenever it notices
nodes join and leave the cluster. The controller uses the epoch number to prevent a
“split brain” scenario where two nodes believe each is the current controller.
  Broker负责处理生产者生产消息的哀求、存储消息、消费者消费消息的哀求。
   A single Kafka server is called a broker. The broker receives messages from producers,
assigns offsets to them, and commits the messages to storage on disk. It also services
consumers, responding to fetch requests for partitions and responding with the mes‐
sages that have been committed to disk
来自Kafka权威指南第1章>Enter Kafka > Broker And Clusters
  Listener的各种配置

当时看官方文档的时候，这部门不停被搞得晕头转向，直到看到这篇关于Kfaka的Listener文章，才彻底明白了各种listener，强烈保举读一下这篇文章。
listener可分为3种：

• 用来推举Controller的listener
  
• kafka集群内部各broker节点通信的listener
  
• 外部客户端，比方Java Client连接Kafka
  

相识了3中controller，联合上面的这篇文章+Apache Kafka官方文档的配置说明，配置listener就变得很轻易了。
Kafka UI配置项说明

注意UI配置中的METRICS_PORT要设置成Kafka配置中的JMX_PORT，至于为什么，相识JMX原理的同学应该都知道，不清晰JMX的可参考JMX快速入门。
轻微有心的同学，大概发现，在docker compose中要访问另外一个服务，需要利用container_service_host_name:port（Docker官方文档Networking in Compose部门），但是这里配置项中只配置了port，Kafka UI是如何拼接JMX的URL呢？我去看了一下它的源码，发现它是可以拿到host的，以是这里不用担心

对于其他UI配置项没什么特殊要说的，这里只是提一下，注意这里的docker-compose.yml中environment的写法，和上面的Kafka镜像中environment的写法不同，这是两种不同的写法
详细文档见Docker Compose文档规范中environment章节

测试

利用上述docker-compose.yml文件，启动

1. docker-compose -f docker-compose.yml up -d

复制代码

在当地浏览器打开

1. http://localhost:9095/kafkaui/auth

复制代码

输入用户名、暗码，进入UI界面

Kafka集群

本篇文章重点在于搭建单机版Kfaka情况，集群不在文章讨论范围之内，如果对集群配置感兴趣和有需要的同学，这里仅给出几个示例的Github仓库仅供参考，并且全部利用KRaft而不是Zookeeper
一个基本的高可用Kafka集群需要多少个节点?

我个人的理解，最小的集群应该是3个controller+3个broker, 为什么是3个broker呢？Kafka官方文档Replication一节 提到过
   With this ISR model and f+1 replicas, a Kafka topic can tolerate f failures without losing committed messages
  意思是，如果topic的复制因子replication factor是2（复制因子是包括leader的，见官方文档：The total number of replicas including the leader constitute the replication factor），那么在一个节点失败的情况下，Kafka还是可以正常工作的。这里Kafka采取的算法和ZooKeeper, Elasticsearch集群的算法是不一样的。如果换成ZK和ES，只有两个节点，这时ZK和ES是无法工作的。
   The downside of majority vote is that it doesn’t take many failures to leave you with no electable leaders. To tolerate one failure requires three copies of the data, and to tolerate two failures requires five copies of the data. In our experience having only enough redundancy to tolerate a single failure is not enough for a practical system, but doing every write five times, with 5x the disk space requirements and 1/5th the throughput, is not very practical for large volume data problems. This is likely why quorum algorithms more commonly appear for shared cluster configuration such as ZooKeeper but are less common for primary data storage
  那这么看来，Kafka集群实在只需要2个节点就可以了，为什么还是3个节点呢？带着这个疑问，我查了一下stackoverflow，还真有人问过这个题目，见in kafka ha why minimum number of brokers required are 3 and not 2

• 如果复制因子是2，min.insync.replicas也是2，当有一个节点失败时，生产者无法完成写入
  
• 如果复制因子是2，min.insync.replicas是1，当leader失败时，follower则大概没有改消息
  
• 如果复制因子是3，min.insync.replicas是2，当有一个节点失败时，生产者还是可以正常写入
  
• 如果复制因子是3，min.insync.replicas是2，当leader失败时，至少另有一个follower的消息时和leader同步的，以是这时可以完成leader的切换
  

Kafka集群示例配置

Kafka关于KRaft模式下Controller的部署建议

• 2024-05-14更新，官方在3.7.0中引入官方镜像并提供了很多示例，集群的示例参考官方Github库
  
• 来自bitnami的Kafka集群示例，三个节点皆为controller和broker。
  
• 来自confluentic的Kafka集群配置，我个人倾向于这个配置，毕竟confluentic是Kafka商业化的公司，其创始人来自LinkedIn。这里是四个节点，一个controller和3个broker。
  
• 来自Github的Kafka-In-Box，利用4个节点。
  

Kafka vs RabbitMQ vs Pulsar性能对比

见confluent官方博文

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。