Kafka基本概念

注： 楼主最近在找工作中， 特地来复习一些知识点。 这在过程中看到了朱忠华老师的一本书叫 《深入理解Kafka-核心设计与实现原理》, 书中的第一章第一节介绍的就是Kafka基本概念。个人觉得内容言简意赅， 特记录于此 。 并于此特别声明本篇内容非原创， 仅是抄录。 文章内容若有侵权，请联系楼主，必删之。 

 

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

整个Kafka体系结构中引入了一下3个术语：

(1) Producer： 生产者， 也就是发送消息的一方。 生产者负责创建消息，然后将其投递到Kafka中。

(2) Consumer: 消费者， 也就是接受消息的一方。 消费者连接到Kafka上并接受消息，进而进行相应的业务逻辑处理。

(3) Broker：服务代理节点。 对于Kafka而言， Broker可以简单的看作一个独立的Kafka服务节点或Kafka服务实例。 大多数情况下也可以将Broker看作一台Kafka服务器，前提是这台服务器上只部署了一个Kafka实例。一个或多个Broker组成了Kafka集群。一般而言，我们更习惯使用小写字母broker来表示代理服务节点。

 

       在Kafka中还有两个特别重要的概念---主题(Topic) 与 分区(Partition)。 Kafka 中的消息以主题为单位进行归类，生产者负责将消息发送到特定主题（发送到Kafka集群中的每一条消息都要指定一个主题），而消费者负责订阅主题并进行消费。

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

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

     

 

      

      每一条消息被发送到Broker之前， 都会根据分区规则选择存储到哪个具体的分区。如果分区规则设定的合理，所有消息都可以均匀的分配到不同的分区中。 如果一个主题只对应一个文件，那这个文件所在机器的 I/O 将会称为这个主题的性能瓶颈，而分区解决了这个问题。在创建主题的时候可以通过指定的参数来设置分区的个数，当然也可以在主题创建完成之后修改分区的数量，通过增加分区的数量可以实现水平扩展。

      Kafka为分区引入了多副本(Replica)机制， 通过增加副本数量可以提升容灾能力。 同一分区的不同副本中保存的是相同的消息（在同一时刻，副本之间并非完全一样),  副本之间是“一主多从”的关系，其中leader副本负责处理读写请求， follower副本只负责与leader副本的消息同步。副本处于不同的broker中， 当leader副本出现故障时，从follower副本中重新选举新的leader副本对外提供服务。 Kafka通过多副本机制实现了故障的自动转移，当Kafka集群中的某个broker失效时仍能保证服务可用。

      如下图所示， Kafka 集群中有4个broker， 某个主题中有3个分区， 且副本因子(即副本个数)也为3， 如此每个分区便有1个leader副本和2个follower副本。 生产者与消费者只有leader副本进行交互， 而follower副本只负责消息的同步， 很多时候follower副本中的消息相对leader副本而言会有一定的滞后。 

 

     

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

      分区中的所有副本统称为AR(Assigned Replicas)。 所有与leader副本保持一定程度同步的副本（包括leader副本在内）组成ISR( In-Sync Replicas)， ISR集合是AR集合中的一个子集。 消息会先发送到leader副本， 然后follower副本才能从leader副本中拉取消息进行同步， 同步期间内follower副本相对于leader副本而言会有一定程度的滞后。 前面所说的 "一定程度的同步" 是指可忍受的滞后范围， 这个范围可以通过参数进行配置。 与leader副本同步滞后过多的副本(不包括leader副本)组成 OSR (Out-of-Sync Replicas)， 由此可见， AR = ISR+OSR。 在正常情况下， 所有的follower副本都应该与leader副本保持一定程度的同步， 即AR=ISR， OSR 集合为空。 

      leader 副本负责维护和跟踪 ISR 集合中所有follower副本的滞后状态， 当 follower 副本落后太多或失效时， leader 副本会把它从ISR 集合中剔除。 如果OSR 集合中有follower 副本 "追上"了leader副本， 那么leader副本就会把它从OSR 集合转到ISR集合。 默认情况下， 当leader副本发生故障时， 只有在ISR集合中的副本才有资格被选举为新的leader, 而在OSR 集合中的副本则没有任何机会(不过这个原则也可以通过修改相应的参数配置来改变)。

      ISR 与 HW 和 LEO 也有紧密的关系。 HW 是 High Watermark 的缩写， 俗称高水位， 它标识了一个特定的消息偏移量(offset)， 消费者只能拉取到这个offset之前的消息。

      如下图所示， 它代表一个日志文件， 这个日志文件中有9条消息，第一条消息的offset(LogStartOffset)为0， 最后一条消息的offset 为8，offset为9的消息用虚线框表示，代表下一条待写入的消息。日志文件的HW为6， 表示消费者只能拉取offset在0到5之间的消息，而offset为6的消息对消费者而言是不可见的。

   

     

       LEO是Log End Offset的缩写， 它标识当前日志文件中下一条待写入消息的offset, 图中的offset为9的位置即为当前日志文件的LEO, LEO的大小相当于当前日志分区中最后一条消息的offset值加1。 分区ISR集合中的每个副本都会维护自身的LEO, 而ISR集合中最小的LEO即为分区的HW, 对消费者而言只能消费HW之前的消息。

      注意要点：很多资料中误将上图中的offset为5的位置看作HW, 而把offset为8的位置看作LEO, 这显然是不对的。

 

      为了让读者更好的理解ISR集合，以及 HW 和 LEO 之间的关系， 下面通过一个简单的示例来来进行相关的说明。 如图1-5所示，假设某个分区的ISR集合中有3个副本， 即一个leader副本和2个follower副本， 此时分区的LEO 和HW 都为3。 消息3 和 消息4从生产者出发之后会被先存入leader副本， 如图1-6所示。

 

   

      在消息写入leader副本之后， follower副本会发送拉取请求来拉取消息3和消息4以进行消息同步。

      在同步过程中， 不同的follower副本的同步效率也不尽相同。如图1-7所示, 在某一时刻follower1完全跟上了leader副本而follower2只同步了消息3， 如此leader副本的LEO为5， follower1的LEO为5， follower2的LEO为4， 那么当前分区的HW取最小值4， 此时消费者可以消费到offset为0到3之间的消息。

       

 

       写入消息如下图所示， 所有的副本都成功写入了消息3和消息4， 整个分区的HW 和 LEO 都变成了5， 因此消费者可以消费到offset为4的消息了。 

     

        由此可见， Kafka 的复制机制既不是完全的同步机制， 也不是单纯的异步复制。 事实上， 同步复制要求所有能工作的follower副本都复制完， 这条消息才会被确认为已经成功提交， 这种复制方式极大地影响了性能。 而在异步复制方式下， follower 副本异步地从leader副本复制数据， 数据只要被leader副本写入就被认为已经提交成功。 在这种情况下， 如果follower副本都还没有复制完而落后于leader副本，突然leader副本宕机， 则会造成数据丢失。 Kafka使用的这种ISR的方式则有效的权衡了数据可靠性和性能之间的关系。 

 

—— THE END ——