Kafka的基本概念

客户端Client：包括消息生产者和消息消费者；
消费者组：每个消费者可以指定一个所属的消费者组，相同消费者组的消费者共同构成一个逻辑消费者组。每个消息会被多个感兴趣的消费者组消费，但是在同一个消费者组内部，一个消息只能被消费一次。
服务端Broker：一个Kafka服务器就是一个Broker；
话题Topic：Topic是一个逻辑概念，而Partition是实际存储消息的组件。每个Partition就是一个queue队列。所有消息以FIFO先进先出的顺序保存在这些Partition中。

1.3.Kafka实现的日志聚合

特点：

1.数据吞吐量大：能够快速收集各个渠道的海量日志。

2.功能不需要太复杂：Kafka的设计目标是高吞吐、低延迟和可扩展，主要关注消息传递而不是消息处理。所以，Kafka没有支持死信队列、顺序消息等功能。

1.4简单的收发消息

Kafka的基础工作机制是消息发送者可以将消息发送到Kafka指定的topic，而消息消费者，可以从指定的topic上消费消息。

1.5其他消费模式

Kafka提供了丰富的消息消费方式。

1.5.1指定消费进度

如果想要消费之前发送的消息，可以通过指定参数--from-begin。

如果需要更精确的消费消息，可以指定从那条消息开始消费。

1.5.2分组消费

对于每个消费者，可以指定一个消费者组。Kafka中的同一条消息，只能被同一个消费者组下的消费者消费。而不属于同一个组的消费者，也可以消费到这一条消息。

1.5.3查看消费者组的偏移量

接下来，还可以使用kafka-consumer-groups.sh观测消费者组的情况。包括他们的消费进度。

1.6基于Zookeeper的Kafka集群

1.6.1使用集群的原因

消息太多，需要分开存放。Kafka是面向海量消息设计的，一个Topic下的消息会非常多，单机服务很难存得下来。这些消息就需要分成不同的Partition，分布到多个不同的Broker上。这样每个Broker就只需要保存一部分数据。这些分区的个数就称为分区数。
服务不稳定，消息容易丢失。单机服务下，如果服务崩溃，数据就丢失了。为了保证数据安全，就需要给每个Partition配置一个或多个备份，保证数据不丢失 。Kafka的集群模式下，每个Partition都有一个或多个备份。Kafka会通过一个统一的Zookeeper集群作为选举中心，给每个Partition选举出一个主节点Leader ，其他节点就是从节点Follower。主节点负责响应客户端的具体业务请求，并保存消息。而从节点则负责同步主节点的数据。当主节点发生故障时，Kafka会选举出一个从节点成为新的主节点。

Kafka集群中的这些Broker信息，包括Partition的选举信息，都会保存在额外部署的Zookeeper集群当中 ，这样，kafka集群就不会因为某一些Broker服务崩溃而中断。Zookeeper是一种多数同意的选举机制，允许集群中少数节点出现故障。

1.6.2Kafka集群架构

1.6.3Topic下的Partition分布情况

在Broker上，与消息联系最为紧密的，就是Partition。之前在配置Kafka集群时，指定了一个log.dirs属性，指向了一个服务器上的日志目录。进入这个目录，就能看到每个Broker的实际数据承载情况。

Broker上的一个Partition对应了日志目录中的一个目录 。而这个Partition上的所有消息，就保存在这个对应的目录当中。

Kafka当中，Topic是一个数据集合的逻辑单元 。同一个Topic下的数据，实际上是存储在Partition分区中的，Partition就是数据存储的物理单元 。而Broker是Partition的物理载体，这些Partition分区会尽量均匀的分配到不同的Broker机器上。而之前接触到的offset，就是每个消息在partition上的偏移量。

1.6.4Kafka集群的整体结构

Topic是一个逻辑概念，Producer和Consumer通过Topic进行业务沟通。
Topic并不存储数据，Topic下的数据分为多组Partition，尽量平均的分散到各个Broker上。每组Partition包含Topic下一部分的消息。每组Partition包含一个Leader Partion以及若干个Follower Partition进行备份。每组Partition的个数成为备份因子replica factor。
Producer将消息发送到对应的Partition上，然后Consumer通过Partition的Offset偏移量，记录自己所属消费者组Group在当前Partition上消费消息的进度。
Producer发送一个Topic的消息，会由Kafka推送给订阅了这个Topic的消费者组进行处理。但是在每个消费者组内部，只会有一个消费者实例处理这一条消息。
Kafka的Broker通过Zookeeper组成集群。然后在这些Broker中，需要选举产生一个担任Controller角色的Broker 。这个Controller的主要任务就是负责Topic的分配以及后续管理工作。在我们实验的集群中，这个Controller实际上是通过ZooKeeper产生的。

1.7Kraft集群

使用Kraft集群后，Kafka集群就不再需要依赖Zookeeper，将之前基于Zookeeper管理的集群数据，转为由Kafka集群自己管理。（目前用的比较少）

传统的Kafka集群，会将每个节点的状态信息统一保存在Zookeeper中，并通过Zookeeper动态选举产生一个Controller节点，通过Controller节点来管理Kafka集群，比如触发Partition的选举。而在Kraft集群中，会固定配置几台Broker节点来共同担任Controller的角色 ，各组Partition的Leader节点就会由这些Controller选举产生。原本保存在Zookeeper中的元数据也转而保存到Controller节点中。

补充：Raft协议是目前进行去中心化集群管理的一种常见算法 ，类似于之前的Paxos协议，是一种基于多数同意，从而产生集群共识的分布式算法。Kraft则是Kafka基于Raft协议进行的定制算法。