Kafka随记

Kafka（分布式流平台）

1. Kafka是一个分布式系统，易于向外扩展
2. 同时为发布和订阅提供高吞吐量
3. 支持多订阅者，当失败时能自动平衡消费者
4. 消息的持久化

Kafka架构图

1. Kafka架构中，拥有多个Producer、Broker、Consumer，且每个Producer对应多个Topic，而每个Consumer只能对应一个Consumer Group
2. 整个Kafka架构对应一个ZooKeeper集群，通过ZooKeeper管理集群选举Leader，并在Consumer Group发生变化时进行Rebalance

名称	说明
Broker	消息中间件的处理节点；一个Kafka节点就是一个Broker，一个或者多个Broker可以组成一个Kafka集群
Topic	消息的主题；Kafka根据Topic对消息进行分类，发布到Kafka集群的每条消息都需要指定一个Topic
Producer	消息生产者，向Broker发送消息的客户端
Consumer	消息消费者，从Broker读取消息的客户端
Consumer Group	每个Consumer属于一个特定的Consumer Group，一条消息可以发送到多个不同的Consumer Group，但是一个Consumer Group中只能有一个Consumer能够消费该消息
Partition	分区。物理上的概念，一个Topic可以分为多个Partition，每个Partition内部是有序的

Topic

1. Topic在逻辑上可以被认为是一个queue，每条消费都必须指定它的Topic，简单的可以理解为必须指明把这条消息放进哪个queue里。
2. 为了使Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition（分区），每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。
3. 对于message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。不过因为磁盘限制，不可能永久保留所有数据，所以，Kafka提供两种策略删除旧数据：一是时间，二是基于Partition文件大小。如下图所示，可以自定义Kafka数据保留时间、数据删除大小、数据检查周期。
   
   由于Kafka读取特定消息的时间复杂度为O(1)，与文件大小无关，所以这里删除过期文件与提高Kafka性能无关，选择怎样的删除策略只与磁盘以及具体的需求有关，Kafka会为每一个Consumer Group保留一些metadata信息——当前消费的消息的position，也即offset。这个offset由Consumer控制。正常情况下Consumer会在消费完一条消息后递增该offset。当然，Consumer也可将offset设成一个较小的值，重新消费一些消息。因为offet由Consumer控制，所以Kafka broker是无状态的，它不需要标记哪些消息被哪些消费过，也不需要通过broker去保证同一个Consumer Group只有一个Consumer能消费某一条消息，因此也就不需要锁机制，这也为Kafka的高吞吐率提供了有力保障。

Producer

1. producer发送消息到Broker时，会根据Partition机制选择将其存储到哪一个Partition。
2. 如果Partition机制合理，所有消息可以均匀分布到不同的Partition里，这就实现了负载均衡。
3. 如果一个Topic对应一个文件，那么文件所在的机器I/O将会成为这个Topic的性能瓶颈，而有了Partition后，不同消息可以并行的写入不同Broker的不同Partition里，极大的提高了吞吐率。

Consumer Group

同一个Topic的一条消息只能被同一个Consumer Group内的Consumer消费，但多个Consumer Group可同时消费这一条消息。
这是Kafka用来实现一个Topic消息的广播（发送给所有Consumer）和单播（发送给某一个Consumer）的手段。一个Topic可以对应多个Consumer Group。
如果需要实现广播，只要每个Consumer有一个独立的Group就可以了。要实现单播只要所有的Consumer在同一个Group中。用Consumer Group还可以将Consumer进行自由的分组而不需要多次发送消息到不同的Topic中。