【Kafka二】Kafka工作原理详解

jokerchu

Kafka系统的角色

• Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。一个Broker上可以有一个Topic的多个Partition，每个Partition的Lead随机存在于某一个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发消息的客户端（Push）。
  
• Consumer ：消息消费者，向kafka broker取消息的客户端(Pull)
  

　　

 

• Consumer Group （CG）：消息系统有两类，一是广播，二是订阅发布。广播是把消息发送给所有的消费者；发布订阅是把消息只发送给一个订阅者。Kafka通过Consumer Group组合实现了这两种机制： 实现一个topic消息广播（发给所有的consumer）和单播（发给任意一个consumer）。一个 topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个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来实现)
  
  

　　消息多播的实现：
　　为一个Topic指定多个Consumer Group，每个Consumer Group指定一个Consumer，那么由于消息会发送给所有的Consumer Group，那么所有的Consumer都会消费这个消息
　　消息单播的实现：
　　为一个Topic指定一个Consumer Group，这个Consumer Group指定多个Consumer，那么由于消息发送给这个Consumer Group时只有一个Consumer消费，这就实现了一个消息只被一个Consumer消费的效果
　　

 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) ----那Producer还是需要知道Broker的状态啊，是不是Producer也需要监听Zookeeper以获取Broker的最新状态？但是ProducerConfig类中没有关于Zookeeper的信息
  
  
• Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition的leader建立socket连接并发送消息。从这句话中，可以看出，每个Topic的partition是由Lead角色的
  
• 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是瞬态的，可以发送后关闭，无需直接等待)

[zk: localhost:2181(CONNECTED) 0] ls /
[admin, consumers, config, brokers]
　　 admin：

[zk: localhost:2181(CONNECTED) 15] ls /admin
[delete_topics]
[zk: localhost:2181(CONNECTED) 16] ls /admin/delete_topics
[]
　　 consumers：（consumers底下是consumer group，consumer group之下有owner，owner是topic的名字）

[zk: localhost:2181(CONNECTED) 7] ls /consumers
[test-consumer-group]
[zk: localhost:2181(CONNECTED) 8] ls /consumers/test-consumer-group
[owners, ids]
[zk: localhost:2181(CONNECTED) 9] ls /consumers/test-consumer-group/owners
[test]
[zk: localhost:2181(CONNECTED) 10] ls /consumers/test-consumer-group/ids   
[]
　　 config:

[zk: localhost:2181(CONNECTED) 11] ls /config
[topics, changes]
[zk: localhost:2181(CONNECTED) 12] ls /config/topics
[test]
[zk: localhost:2181(CONNECTED) 13] ls /config/changes
[]
　　 brokers:

[zk: localhost:2181(CONNECTED) 3] ls /brokers
[topics, ids]
[zk: localhost:2181(CONNECTED) 4] ls /brokers/topics
[test]
[zk: localhost:2181(CONNECTED) 5] ls /brokers/ids
[]
　　 
　　推荐阅读：
　　http://www.michael-noll.com/blog/2013/03/13/running-a-multi-broker-apache-kafka-cluster-on-a-single-node/