Kafka 的三大角色：

消息系统：

Kafka 和传统的消息系统（也称作消息中间件〉都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时， Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。

存储系统：

Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。也正是得益于Kafka 的消息持久化功能和多副本机制，我们可以把Kafka 作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置为“永久”或启用主题的日志压缩功能即可。

流式处理平台：

Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。

基本概念

一个典型的Kafka体系架构包括：

Producer

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

Broker

服务代理节点。对于Kafka 而言，Broker 可以简单地看作一个独立的Kafka服务节点或Kafka 服务实例。大多数情况下也可以将Broker 看作一台Kafka 服务器，前提是这台服务器上只部署了一个Kafka 实例。一个或多个Broker 组成了一个Kafka 集群。

Consumer

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

ZooKeeper集群

ZooKeeper 是Kafka 用来负责集群元数据的管理、控制器的选举等操作的。

Kafka的2个重要概念-Topic和Partition

Topic

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

Partition

主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题，很多时候也会把分区称为主题分区（ Topic-Partition ）。同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志（ Log ）文件。

分区可以分布在不同的服务器（ broker ）上，也就是说，一个主题可以横跨多个broker ，以此来提供比单个broker 更强大的性能。

offset

消息在被追加到分区日志、文件的时候都会分配一个特定的偏移量（ offset ）。offset 是消息在分区中的唯一标识， Kafka 通过它来保证消息在分区内的顺序性，不过offset 并不跨越分区，也就是说， Kafka 保证的是分区有序而不是主题有序。

多副本架构

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

术语

AR ( Assigned Replicas)

分区中的所有副本统。

ISR(On-Sync Replicas )

所有与leader 副本保持一定程度同步的副本（包括leader 副本在内〕组成 , ISR 集合是AR 集合中的一个子集。

消息会先发送到leader副本，然后follower 副本才能从leader 副本中拉取消息进行同步，同步期间内follower 副本相对于leader 副本而言会有一定程度的滞后。前面所说的“ 一定程度的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置

OSR ( Out-of-Sync Replicas )

与leader 副本同步滞后过多的副本（不包括leader 副本）

HW(High Watermark)

它标识了一个特定的消息偏移量（ offset ），消费者只能拉取到这个offset 之前的消息。

LEO(Log End Offset)

它标识当前日志文件中下一条待写入消息的offset，LEO 的大小相当于当前日志分区中最后一条消息的offset值加1 。分区ISR 集合中的每个副本都会维护自身的LEO.

分区中各偏移量位置

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

HW与LEO关系

为了让读者更好地理解ISR 集合，以及HW 和LEO 之间的关系，下面通过一个简单的示例来进行相关的说明。

假设某个分区的ISR 集合中有3 个副本，即一个leader副本和2 个follower 副本，此时分区的LEO 和HW 都为3 。

消息3 和消息4 从生产者发出之后会被先存入leader 副本：

在消息写入leader 副本之后， fo llower 副本会发送拉取请求来拉取消息3 和消息4 以进行消息同步。在同步过程中，不同的follower副本的同步效率也不尽相同。

所有的副本都成功写入了消息3 和消息4

深入理解Kafka（1）相关推荐

《深入理解Kafka:核心设计与实践原理》笔误及改进记录
2019年2月下旬笔者的有一本新书--<深入理解Kafka:核心设计与实践原理>上架,延续上一本<RabbitMQ实战指南>的惯例,本篇博文用来记录现在发现的一些笔误,一是给购 ...
新书《深入理解Kafka：核心设计与实践原理》上架，感谢支持~
新书上架初识 Kafka 时,笔者接触的还是 0.8.1 版本,Kafka 发展到目前的 2.x 版本,笔者也见证了Kafka的蜕变,比如旧版客户端的淘汰.新版客户端的设计.Kafka 控制器的迭代 ...
Kafka科普系列 | 轻松理解Kafka中的延时操作
欢迎跳转到本文的原文链接:https://honeypps.com/mq/kafka-basic-knowledge-of-delay-operation/ 本文起源于之前去面试的一道面试题,面试题大 ...
取本地数据_深入理解Kafka服务端之Follower副本如何同步Leader副本的数据
一.场景分析Kafka采用的是主写主读的方式,即客户端的读写请求都由分区的Leader副本处理,那么Follower副本要想保证和Leader副本数据一致,就需要不断地从Leader副本拉取消息来进行 ...
深入理解kafka_深入理解Kafka随书代码示例已整理完毕，附地址~
<深入理解Kafka>中大多都是以文字或者图片的形式来陈述,但是书中也有一些示例代码,尤其在书本的前1/3部分,为了让Kafka新手能够适应,会有些许demo呈现. 其实在写这本书的时候, ...
一文理解kafka端到端的延迟
前言: 在大规模的使用kafka过程中,我们通常会遇到各种各样的问题,比如说,通常会有一些大数据集群中的Job发现总有几个task会比较慢,导致整体的任务迟迟不能完成运行,这种情况通常问题会比较复杂, ...
Kafka系列之：深入理解Kafka 主题、分区、副本、LEO、ISR、HW、Kafka的主写主读和分区leader选举
Kafka系列之:深入理解Kafka 主题.分区.副本.LEO.ISR.HW.Kafka的主写主读和分区leader选举一.Kafka重要知识点提炼二.详细介绍Kafka 主题.分区.副本.LEO ...
深入理解Kafka核心设计与实践原理_01
深入理解Kafka核心设计与实践原理_01 01_初识Kafka 1.1 基本概念 1.2 安装与配置 1.3 生产与消费 1.4 服务端参数配置 01_初识Kafka 1.1 基本概念一个典型的 ...
深入理解kafka原理
今天深入理解kafka原理,首先生产的原理图如下: 一.集群的成员关系: Kafka 使用 zookeeper 来维护集群成员的信息.每个 broker 都有个唯一标识符, 这个标识符可以在配置文件里 ...
kafka 同步提交异步_腾讯游戏工程师分享：简单理解 Kafka 的消息可靠性策略
作者:hymanzhang,腾讯 IEG 运营开发工程师背景部门的开发同学最近在开发一个活动的过程中,需要关注大量的应用后台逻辑,捕捉各种事件的触发.在设计时打算采用 kafka 消息队列进行业务 ...

深入理解Kafka（1）