Kafka学习记录
Kafka适合什么样的场景?
它可以用于两大类别的应用:
- 构造实时流数据管道，它可以在系统或应用之间可靠地获取数据。 (相当于message queue)
- 构建实时流式应用程序，对这些流数据进行转换或者影响。 (就是流处理，通过kafka stream topic和topic之间内部进行变化)
以下是一些基本的概念
1.生产者 Producer
负责生产消息并塞入到kafka服务器中
2.集群 Broker
每一个kafka运行的进程就可以理解为是一个broker
3.发布与订阅 Publish & Subscribe
kafka中间件是基于发布与订阅的架构，生产者将消息发布到主题，由不同消费者订阅不同的主题，获取对应的数据
4.主题 Topic
用于消息分类，不同类型的消息塞入到不同的主题中，消费者只关注自己订阅的topic消息；可进行分区，每个分区都有对应的副本
5.分区 Partition
提高topic的负载均衡，一个topic可以分多个partition
6.主从机制 Leader& Follower
消费者只与leader直连，follower的存在仅仅只是用于备份。
Kakfa Broker Leader的选举：Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（这个过程叫Controller在ZooKeeper注册Watch）。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。例如：一旦有一个broker宕机了，这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态，并选取ISR列表中的一个replica作为partition leader（如果ISR列表中的replica全挂，选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了，则将新的leader设置为-1，等待恢复，等待ISR中的任一个Replica“活”过来，并且选它作为Leader；或选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader），这个broker宕机的事情，kafka controller也会通知zookeeper，zookeeper就会通知其他的kafka broker。
7.消费者 Consumer
从主题分区中拉取数据，一般由Consumer Group组成，同一个主题分区只能被一个消费者组里面的某一个消费者消费