kafka系列——基础概念介绍

国际惯例的简单介绍

kafka是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，有着如下优秀的特性：     

高吞吐、低延迟：kafka每秒可以处理几十万条消息，延迟最低只有几毫秒，每个topic可以分多个分区, 消费者组对分区进行消费操作     

可扩展性：kafka集群支持热扩展     

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失     

容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）   

 高并发：支持多个客户端同时读写

 基础概念介绍：

topic主题：一组消息抽象归纳为一个topic，是对消息的一个逻辑分类，简单理解就是一个队列名

message消息：kafka通信的基本单位，主要由offset  key  value  timestamp构成

partition分区：维护kafka消息数据的最小单位，一个topic可包含多个partition，每个分区由一系列有序且不可
变的消息组成，partition在物理上对应为一个文件夹，partition的命名规则为topic名称加”-”，再加分区编号

replica副本：是partition的备份，一个partition可以存在1个or多个replica，分布在集群不同代理上

leader副本与follower副本：为保证一个partition的多个replica之间数据的一致性，kafka会在replica中选择一个作为
leader副本，其余为follower副本，只有leader副本负责客户端的write/read请求，follower副本从leader副本同步数
据，若leader副本失效，则选举其他follower副本为新的leader副本

offset偏移量：任何发布到分区的message会被直接追加到日志文件尾部，而每条message在日志文件中的位置都会
对应一个按序递增的offset，是一个partition下严格有序的逻辑值，不代表message在磁盘上的物理位置

日志段logSegment：一个日志被划分为多个日志段，是kafka日志对象分片的最小单位，是一个逻辑概念，一个日志
段对应磁盘上一个具体的日志文件和两个索引文件；日志文件以.log为后缀，保存消息实际数据，索引文件分别
以.index与.timeindex为后缀，分别表示消息偏移量索引文件与消息时间戳索引文件

broker代理：kafka集群中的机器/服务被称为broker，一个kafka集群由一个or多个kafka代理组成，每个broker都要有 一个非负整数的唯一标识id，通过broker.id配置

producer生产者：负责将消息发送给broker，即向kafka代理发送消息的客户端

consumer消费者：kafka中通过zookeeper，负责以pull拉取方式拉取数据的客户端，每个consumer也有一个全局唯 一的id，可通过client.id配置

consumer group消费者组：kafka中每一个消费者都属于一个特定的consumer group，通过group.id配置，一个 consumer group可以包含多个consumer，若不指定consumer group，则默认属于test-consumer-group，同一topic的 一条message只能被同一consumer group下的某一个consumer消费，但不同的consumer group的consumer可同时 消费该message，consumer group是kafka用来实现对一个topic消息进行广播(consumer属于不同consumer group时) 与单播(consumer属于同一consumer group)的手段

ISR同步副本列表：该列表保存的是与leader副本保持消息同步的所有副本对应的brokerId，若一个follower副本宕机 或落后太多，则该follower副本将从ISR列表移除

zookeeper：kafka使用zookeeper保存如代理节点信息、Kafka集群信息、旧版消费者信息及其消费者偏移量信息、主 题信息、分区状态信息、分区副本分配方案信息、动态配置信息等元数据信息，kafka在启动or运行过程中会在 zookeeper上创建相应的节点来保存元数据信息，kafka通过监听机制在这些节点注册相应的监听器来监听节点元数据 的变化，从而由zookeeper负责维护管理kafka集群

kafka集群的基本架构图：

kafka对应的zookeeper中节点信息介绍：

生产者版本介绍：

旧版生产者(scala实现)：在发送消息时候根据配置producer.type来决定是同步/异步发送,不同发送方式,执行逻辑不同

异步发送逻辑如下：

             

同步发送逻辑如下：

             

同步/异步区别：异步模式会首先将消息存入到消息队列，然后由一个独立的线程判断是否需要将数据向代理发送

新版生产者(java实现)：设计思路上与旧版的异步模式类似,只是实现细节与采用的数据结构略有不同；而且旧版本 同步与异步模式是分开实现的,而新版本的同步模式是通过异步模式实现的；因为新版本异步发送消息的 send(ProducerRecord<K, V> record)方法是返回一个Future<RecordMetadata>对象,只需调用Future的get()即可实现 消息同步发送(后面章节详细介绍)

消费者版本介绍：

旧版消费者(scala实现)：分别为SimpleConsumer和ZookeeperConsumerConnector，前者为低级旧版消费者，后者 为高级旧版消费者，两者的区别如下：

新版消费者(java实现)：非线程安全,直接与指定的broker进行连接,无需依赖zookeeper,启动消费者时不向zookeeper 注册,而是由消费组协调器统一管理,已消费消息的偏移量提交后会保存到名为”_consumer_offsets”的内部主题中,且提 供了一系列简易的api(后面章节详细介绍)

ISR同步机制：

ISR集合：指目前可用且消息量与leader副本相差不多的副本集合

ISR集合中的副本须满足以下条件：

A. 副本所在节点必须与zookeeper保持连接

B. 副本最后一条消息的offset与leader副本最后一条消息的offset之间的差值不能超过指定阈值,可通过 replica.lag.max.messages配置来指定

C. 副本需一直同步leader副本的消息,若在指定时间阈值内未同步,则从ISR集合中移除,可通过replica.lag.time.max.ms 配置来指定

每个分区的leader副本会维护自己分区的ISR集合,写请求首先在leader副本上处理,之后follower副本会从leader副本拉 取写入消息,当follower副本出现异常违反上面3个条件的1个or多个,则会被剔除ISR集合,等异常恢复后又会与leader副本 进行同步,当follower副本“追上”leader副本时候,又会重新加入ISR集合

HW(High WaterMark)：HW标记了一个特殊的offset,当消费者处理消息时候,只能拉取到HW之前的消息,HW之后的消息 对消费者来说是不可见的(即使已经在leader副本处理了),只有当ISR集合中全部的follower副本都拉取HW指定消息进行 同步后,leader副本会递增HW的值,此时消费者才可以消费到上一个HW之前的消息,此时即便leader副本损坏,也不会丢 数据；HW也是由leader副本管理的

LEO(Log End Offset)：所有副本都会有的一个offset标记,指向追加到当前副本的最后一个消息的offset,当生产者向 leader副本追加消息时候,leader副本的LEO标记会递增;当follower副本成功从leader副本拉取消息并更新到本地时, follower副本的LEO就会增加

例子,针对offset=11的消息,ISR集合、HW和LEO是如何协调工作的：

① producer向此partition推送消息

② leader副本将消息追加到log中并递增其LEO

③ follower副本从leader副本拉取消息进行同步

④ follower副本将拉取到的消息更新到本地log中并递增自身LEO

⑤ 当ISR集合中所有副本都完成对offset=11的消息的同步,leader副本会递增HW

这部分完~