CC00004.kafka——|Hadoop&kafka.V04|——|kafka.v04|基本架构|核心概念.v03|

一、核心概念

### --- Producer：生产者创建消息。

~~~     该角色将消息发布到Kafka的topic中。
~~~     broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment 文件中。
~~~     # 一般情况下，一个消息会被发布到一个特定的主题上。
~~~     默认情况下通过轮询把消息均衡地分布到主题的所有分区上。
~~~     在某些情况下，生产者会把消息直接写到指定的分区。
~~~     这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。
~~~     这样可以保证包含同一个键的消息会被写到同一个分区上。
~~~     生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。

### --- Consumer：消费者读取消息。

~~~     消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。
~~~     消费者通过检查消息的偏移量来区分已经读取过的消息。
~~~     偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。
~~~     在给定的分区里，每个消息的偏移量都是唯一的。
~~~     消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka上，
~~~     如果消费者关闭或重启，它的读取状态不会丢失。
~~~     消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。
~~~     如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配。

### --- Broker：一个独立的Kafka 服务器被称为broker。

~~~     # broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。
~~~     如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
~~~     如果某topic有N个partition，集群有(N+M)个broker，
~~~     那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
~~~     如果某topic有N个partition，集群中broker数目少于N个，
~~~     那么一个broker存储该topic的一个或多个partition。
~~~     在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。
~~~     broker 是集群的组成部分。
~~~     每个集群都有一个broker 同时充当了集群控制器的角色(自动从集群的活跃成员中选举出来)。
~~~     控制器负责管理工作，包括将分区分配给broker 和监控broker。

三、在集群中，一个分区从属于一个broker，该broker 被称为分区的首领。

### --- Topic

~~~     每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
~~~     物理上不同Topic的消息分开存储。
~~~     主题就好比数据库的表，尤其是分库分表之后的逻辑表。

### --- Partition

~~~     主题可以被分为若干个分区，一个分区就是一个提交日志。
~~~     消息以追加的方式写入分区，然后以先入先出的顺序读取。
~~~     无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。
~~~     Kafka 通过分区来实现数据冗余和伸缩性。
~~~     在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

### --- Replicas

~~~     Kafka 使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本。
~~~     那些副本被保存在broker 上，每个broker 可以保存成百上千个属于不同主题和分区的副本。

### --- 副本有以下两种类型：

~~~     # 首领副本
~~~     每个分区都有一个首领副本。为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。
~~~     # 跟随者副本
~~~     首领以外的副本都是跟随者副本。
~~~     跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领那里复制消息，
~~~     保持与首领一致的状态。如果首领发生崩溃，其中的一个跟随者会被提升为新首领。

### --- Offset：

~~~     # 生产者Offset
~~~     消息写入的时候，每一个分区都有一个offset，这个offset就是生产者的offset，
~~~     同时也是这个分区的最新最大的offset。
~~~     有些时候没有指定某一个分区的offset，这个工作kafka帮我们完成。

### --- 消费者Offset

~~~     这是某一个分区的offset情况，
~~~     生产者写入的offset是最新最大的值是12，
~~~     而当Consumer A进行消费时，从0开始消费，一直消费到了9，消费者的offset就记录在9，
~~~     Consumer B就纪录在了11。
~~~     等下一次他们再来消费时，他们可以选择接着上一次的位置消费，
~~~     当然也可以选择从头消费，或者跳到最近的记录并从“现在”开始消费。

### --- 副本

~~~     Kafka通过副本保证高可用。副本分为首领副本(Leader)和跟随者副本(Follower)。
~~~     跟随者副本包括同步副本和不同步副本在发生首领副本切换的时候，只有同步副本可以切换为首领副本。

~~~     # AR
~~~     分区中的所有副本统称为AR(Assigned Repllicas)。
~~~     AR=ISR+OSR

~~~     # ISR
~~~     所有与leader副本保持一定程度同步的副本(包括Leader)组成ISR(In-Sync Replicas)，
~~~     ISR集合是AR集合中的一个子集。
~~~     消息会先发送到leader副本，然后follower副本才能从leader副本中拉取消息进行同步，
~~~     同步期间内follower副本相对于leader副本而言会有一定程度的滞后。
~~~     前面所说的“一定程度”是指可以忍受的滞后范围，这个范围可以通过参数进行配置。

~~~     # OSR
~~~     与leader副本同步滞后过多的副本(不包括leader)副本，组成OSR(Out-Sync Relipcas)。
~~~     在正常情况下，所有的follower副本都应该与leader副本保持一定程度的同步，
~~~     即AR=ISR,OSR集合为空。

~~~     # HW
~~~     HW是High Watermak的缩写， 俗称高水位，它表示了一个特定消息的偏移量(offset)，
~~~     消费之只能拉取到这个offset之前的消息。

~~~     # LEO
~~~     LEO是Log End Offset的缩写，它表示了当前日志文件中下一条待写入消息的offset。