体系架构

一个典型的Kafka架构包括若干Producer、若干Broker、若干Consumer，以及一个Zookeeper集群。其中Zookeeper是Kafka用来负责集群元数据的管理、控制器的选举等操作的。Producer将消息发送到Broker，Broker负责将收到的消息存储到磁盘中，而Consumer负责从Broker订阅并消费消息。

相关术语：

• Producer:生产者，也就是发送消息的一方。生产者负责创建消息，然后将其投递到Kafka中。
• Consumer:消费者，也就是接收消息的一方。消费者连接到Kafka上并接收消息，进而进行相应的业务逻辑处理。
• Broker：服务代理节点。对于Kafka而言，Broker可以简单地看做一个独立的Kafka服务器节点或Kafka服务实例。大多情况下也可以将Broker看做一台Kafka服务器，前提是这台服务器上只部署了一个Kafka实例。一个或多个Broker组成了一个Kafka集群。

主题(Topic)和分区(Partition)

Kafka中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题(发送到Kafka集群中的每一条消息都要指定主题）,而消费者负责订阅主题并进行消费。

主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题，很多时候也会把分区称为主题分区(Topic-Partition)。同一个主题下的不同分区包含的消息是不同的，分区存储层面可以看做一个可追加的日志(Log)文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量(offset)。offset是消息在分区中的唯一标识，Kafka通过它来保证消息在分区内的顺序型，不过offset并不跨越分区，也就是说，Kafka保证的是分区有序而不是主题有序。

如图，主题中有四个分区，消息被顺序追加到每个分区日志文件的尾部。Kafka中的分区可以分布在不同的服务器(broker)上，也就是说，一个主题可以横跨多个broker，以此来提供比单个broker更强大的性能。

如果一个主题只有一个文件，那么这个文件所在的机器I/O将会称为这个主题的性能瓶颈，而分区解决了这个问题，

leader和follower

Kafka为分区引入了多副本(Replica)机制，通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同消息，副本之间是“一主多从”的关系，其中leader副本负责处理读写请求，follower副本只负责与leader副本的消息同步。副本处于不同的broker中。

当leader副本出现故障时，从follower中重新选举新的leader副本对外提供服务。---->>>服务高可用

如图，Kafka集群中有4个broker，某个主题中有3个分区，且副本因子为3，每个分区便有1个leader副本和2个follower副本。

follower副本中的消息相对leader副本而言有一定滞后。

消费端的容灾能力(可靠性)：Consumer使用(Pull)拉方式从服务端拉取消息，并且保存消费的具体位置，当消费者宕机后恢复上线时可以根据之前保存的消费位置重新拉取需要的消息进行消费，这样不会造成消息丢失。

AR、ISR、OSR

• AR(Assigned Replicas)：分区中所有副本
• ISR(In-Sync Replicas）：所有与leader副本保持一定程度同步的副本(包括leader)
• OSR(Out-of-Sync Replicas）：与leader副本同步之后过多的副本 AR=ISR+OSR

默认情况下，当leader副本发生故障时，只有在ISR集合中的副本才有机会被选举为新的leader

HW和LEO

• HW(High Watermark)：高水位，标识了一个特定的消息偏移量(offset)，消费者只能拉取到这个offset之前的消息
• LEO(Log End Offset):标识当前日志文件中下一条待写入消息的Offset

分区ISR集合中的每个副本都会维护自身的LEO，而ISR集合中最小的LEO即为分区的HW,对消费者而言只能消费HW之前的消息

假设某个分区的ISR集合中有三个副本(一个leader两个follower)，此时分区的LEO和HW都为3，消息3和消息4从生产者发出后先存入leader副本

总结：

• Kafka的复制机制不是完全的同步复制，也不是单纯的异步复制。
• 同步复制要求所有能工作的follower副本都复制完，消息才被确认为成功提交---->>>影响性能
• 异步复制中数据只要被leader副本读入就认为已经成功提交--->>>leader宕机造成数据丢失
• Kafka权衡了数据可靠性和性能之间的关系