kafka-zookepeper

本文深入解析Kafka消息系统的架构,包括其核心组件如Broker、Topic、Partition及Consumer Group的功能与作用,同时阐述了消息传递机制及Zookeeper在Kafka集群中的关键作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

问题导读

1.Kafka有哪些角色?
2.Partition的作用是什么?
3.Offset的作用是什么?
4.消息系统有哪两类?
5.什么是topic消息广播和单播?
6.Kafka的元数据和Topic是否都存储在zookeeper?









Kafka系统的角色
  • Broker :一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic
  • topic: 可以理解为一个MQ消息队列的名字
  • Partition:为了实现扩展性,一个非常大的topic可以分布到多个 broker(即服务器)上,一个topic可以分为多个partition,每个partition是一个有序的队列。partition中的每条消息 都会被分配一个有序的id(offset)。kafka只保证按一个partition中的顺序将消息发给consumer,不保证一个topic的整体 (多个partition间)的顺序。也就是说,一个topic在集群中可以有多个partition,那么分区的策略是什么?(消息发送到哪个分区上,有两种基本的策略,一是采用Key Hash算法,一是采用Round Robin算法)

 

  • Offset:kafka的存储文件都是按照offset.kafka来命名,用offset做名字的好处是方便查找。例如你想找位于2049的位置,只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka
  • Producer :消息生产者,就是向kafka broker发消息的客户端。
  • Consumer :消息消费者,向kafka broker取消息的客户端

 

  • Consumer Group (CG):消息系统有两类,一是广播,二是订阅发布。广播是把消息发送给所有的消费者;发布订阅是把消息只发送给订阅者。Kafka通过Consumer Group组合实现了这两种机制: 实现一个topic消息广播(发给所有的consumer)和单播(发给任意一个consumer)。一个 topic可以有多个CG。topic的消息会复制(不是真的复制,是概念上的)到所有的CG,但每个CG只会把消息发给该CG中的一个 consumer(这是实现一个Topic多Consumer的关键点:为一个Topic定义一个CG,CG下定义多个Consumer)。如果需要实现广播,只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还 可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。典型的应用场景是,多个Consumer来读取一个Topic(理想情况下是一个Consumer读取Topic的一个Partition),那么可以让这些Consumer属于同一个Consumer Group即可实现消息的多Consumer并行处理,原理是Kafka将一个消息发布出去后,ConsumerGroup中的Consumers可以通过Round Robin的方式进行消费(Consumers之间的负载均衡使用Zookeeper来实现)

 
A two server Kafka cluster hosting four partitions (P0-P3) with two consumer groups. Consumer group A has two consumer instances and group B has four. 



总结:Topic、Partition和Replica的关系: 
 

如上图,一个Topic有四个Partition,每个Partition两个replication。


Zookeeper在Kakfa中扮演的角色Kafka将元数据信息保存在Zookeeper中,但是发送给Topic本身的数据是不会发到Zk上的,否则Zk就疯了。
  • kafka使用zookeeper来实现动态的集群扩展,不需要更改客户端(producer和consumer)的配置。broker会在zookeeper注册并保持相关的元数据(topic,partition信息等)更新。
  • 而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化,客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时,各broker间仍能自动实现负载均衡。这里的客户端指的是Kafka的消息生产端(Producer)和消息消费端(Consumer)
  • Broker端使用zookeeper来注册broker信息,以及监测partition leader存活性.
  • Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息.
  • Zookeer和Producer没有建立关系,只和Brokers、Consumers建立关系以实现负载均衡,即同一个Consumer Group中的Consumers可以实现负载均衡


问题:
1.Topic有多个Partition,那么消息分配到某个Partition的依据是什么?Key Hash或者Round Robin

2. 如何查看一个Topic有多少个Partition?
使用kakfa-topic.sh --list topic topicName --zookeeper zookeeper.servers.list

Zookeeper记录的信息如下列出了在http://bit1129.iteye.com/blog/2174791一文中操作Kafka时,Zk上记录的信息(可见,Zookeeper上没有记录Producer的信息,因为Producer是瞬态的,可以发送后关闭,无需直接等待)


  1. [zk: localhost:2181(CONNECTED) 0] ls /
  2. [admin, consumers, config, brokers]
复制代码


admin:
  1. [zk: localhost:2181(CONNECTED) 15] ls /admin
  2. [delete_topics]
  3. [zk: localhost:2181(CONNECTED) 16] ls /admin/delete_topics
  4. []
复制代码


consumers:(consumers底下是consumer group,consumer group之下有owner,owner是topic的名字)
  1. [zk: localhost:2181(CONNECTED) 7] ls /consumers
  2. [test-consumer-group]
  3. [zk: localhost:2181(CONNECTED) 8] ls /consumers/test-consumer-group
  4. [owners, ids]
  5. [zk: localhost:2181(CONNECTED) 9] ls /consumers/test-consumer-group/owners 
  6. [test]
  7. [zk: localhost:2181(CONNECTED) 10] ls /consumers/test-consumer-group/ids   
  8. []
复制代码
config:
  1. [zk: localhost:2181(CONNECTED) 11] ls /config
  2. [topics, changes]
  3. [zk: localhost:2181(CONNECTED) 12] ls /config/topics
  4. [test]
  5. [zk: localhost:2181(CONNECTED) 13] ls /config/changes
  6. []
复制代码


brokers:
  1. [zk: localhost:2181(CONNECTED) 3] ls /brokers
  2. [topics, ids]
  3. [zk: localhost:2181(CONNECTED) 4] ls /brokers/topics
  4. [test]
  5. [zk: localhost:2181(CONNECTED) 5] ls /brokers/ids
  6. []
复制代码

### Kafka集群启动时遇到Broker主机名无法解析问题的排查与解决 在Kafka集群启动过程中,若出现`ssh: Could not resolve hostname kafka-broker1: Name or service not known`错误,说明系统无法解析指定的Broker主机名。此类问题通常与DNS配置、本地`/etc/hosts`文件配置或Kafka配置文件中的`broker.id`与`listeners`设置相关。 #### 1. 检查主机名解析配置 Kafka节点之间的通信依赖于主机名解析,若使用静态解析(如`/etc/hosts`),则需确保所有节点的`/etc/hosts`文件中包含所有Broker节点的主机名与IP映射关系。例如: ```bash 192.168.1.10 kafka-broker1 192.168.1.11 kafka-broker2 192.168.1.12 kafka-broker3 ``` 若未正确配置上述映射,将导致主机名无法解析,从而引发Kafka启动失败或节点间通信异常的问题[^2]。 #### 2. 验证SSH连接与主机名解析 在Kafka集群部署中,若使用脚本或工具(如`kafka-server-start.sh`)通过SSH远程启动Broker节点,则需确保各节点之间可通过主机名进行SSH连接。执行如下命令测试主机名解析和SSH连接: ```bash ssh kafka-broker1 ``` 若提示`Could not resolve hostname`,则应检查当前节点的`/etc/hosts`文件是否包含目标主机名的正确映射;若提示连接超时或权限问题,则需检查SSH配置及防火墙设置。 #### 3. 核查Kafka配置文件中的主机名设置 Kafka的`server.properties`文件中应配置正确的`broker.id`、`listeners`和`advertised.listeners`。其中,`advertised.listeners`用于指定对外公布的监听地址,若该地址为主机名,则必须确保所有客户端和Broker节点均能解析该主机名。例如: ```properties broker.id=1 listeners=PLAINTEXT://:9092 advertised.listeners=PLAINTEXT://kafka-broker1:9092 ``` 若主机名配置错误或无法解析,Kafka将无法正常启动或加入集群。 #### 4. 使用IP地址作为临时替代方案 若短期内无法解决主机名解析问题,可将`advertised.listeners`配置为IP地址,以避免依赖DNS或`/etc/hosts`。例如: ```properties advertised.listeners=PLAINTEXT://192.168.1.10:9092 ``` 此方法适用于测试环境或临时解决方案,但在生产环境中建议使用规范的DNS解析机制。 #### 5. 确保ZooKeeper配置一致 Kafka依赖ZooKeeper进行集群协调,其配置文件中需指定正确的ZooKeeper连接地址。例如: ```properties zookeeper.connect=kafka-zk1:2181,kafka-zk2:2181,kafka-zk3:2181 ``` 若ZooKeeper节点主机名未正确解析,也可能导致Kafka无法启动。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值