Kafka（四）------Kafka知识点整理_kafka 一个消息会写入所有broker

一、Kafka名词含义解释

1.1、Broker

一台 kafka 服务器就是一个 broker；

多个broker组成一个Kafka集群，集群中每一个broker的id要唯一；

一个 broker可以容纳多个 topic；

1.2、Topic

kafka通过Topic将消息进行分类，每一个消息都具有一个Topic，Topic存储在Broker上。

1.3、partition

一个topic可以分布到多个broker上；

一个 topic 包括多个 partition(分区)，不同的分区对应着不同的数据文件，Kafka使用分区支持物理上的并发写入和读取，从而大大提高了吞吐量；

每个 partition 可以有多个 replica(副本); producer 发送的消息存储在 partition 中；

每个 partition 是一个有序的队列，partition 中的每条消息都会被分配一个有序的 id（offset）；

kafka 只保证按一个 partition 中的顺序将消息发给consumer，不保证一个 topic 的整体（多个 partition 间）的顺序；

1.4、replication

一个分区具有多个副本， 同一个分区中的不同副本保存的是相同的消息；

副本之间的关系是“一主多从”的关系，leader副本负责处理读写请求，follower副本只负责与leader副本的消息同步；

多副本机制提高了容灾能力，支持某个broker失效保障服务可用，及消息的备份。

1.5、Producer

消息生产者，就是向 kafka broker 发消息的客户端

1.6、Consumer

消息消费者，向 kafka broker 取消息的客户端

1.7、Consumer Group

kafka用于实现topic消息的广播与单播方式。

一个 topic 可以有多个 CG，topic 的消息会复制给topic上所有的CG，但每个 partition 只会把消息发给该 CG 中的一个 consumer。

实现广播：每个 consumer 有一个独立的 CG
实现单播：所有的 consumer 在同一个 CG

1.8、offset

每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息。

1.9、Segment

partition物理上由多个segment组成

二、zookeeper在Kafka中发挥的作用

Kafka（六）------Zookeeper在Kafka中发挥的作用

三、ISR

四、使用Kafka有什么优点和缺点

优点：

①支持跨数据中心的消息复制；

②单机吞吐量：十万级，最大的优点，就是吞吐量高;

③topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源;

④时效性：ms级;

⑤可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用;

⑥消息可靠性：经过参数优化配置，消息可以做到0丢失;

⑦功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用。

缺点：

①由于是批量发送，数据并非真正的实时； 仅支持统一分区内消息有序，无法实现全局消息有序；

②有可能消息重复消费；

③依赖zookeeper进行元数据管理，等等。

五、Kafka消息是采用Pull模式，还是Push模式？

Kafka还是选取了传统的pull模式 ：producer将消息推送到broker，consumer从broker拉取消息一些消息

Pull模式

customer从brokes拉取消息
1

优势：consumer可以自主决定是否批量的从broker拉取数据，根据自己的消费能力拉去数据。

劣势：如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞直到新消息到达(当然也可以阻塞直到消息的数量达到某个特定的量这样就可以批量发送）

Push模式

brokers将消息推送到consumer

劣势：在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。

六、Kafka高效文件存储设计特点

Kafka（五）------Kafka文件储存特点

(1).Kafka 把 topic 中一个 parition 大文件分成多个小文件段，通过多个小文件段，就容易定

期清除或删除已经消费完文件，减少磁盘占用。

(2).通过索引信息可以快速定位 message 和确定 response 的最大大小。

(3).通过 index 元数据全部映射到 memory，可以避免 segment file 的 IO 磁盘操作。

(4).通过索引文件稀疏存储，可以大幅降低 index 文件元数据占用空间大小。

七、kafka的ack机制

kafka中的应答机制：

ack作用是确认收到消息，一条是producer发送消息到leader收到消息之后发送ack
另一条是leader和follower之间同步完成数据会发送ack

对于一些不太重要的数据，对数据的可靠性要求不是特别高的情况下，能够容忍少量的数据丢失，因此没有必要等待ISR中所有follower全部要接收成功

所以Kafka为用户提供了三种可靠级别设置，可以根据不同需求来修改选择：

ack:0

意味着producer不等待broker同步完成的确认，继续发送下一条(批)信息

提供了最低的延迟。但是最弱的持久性，当服务器发生故障时，就很可能发生数据丢失。例如leader已经死亡，producer不知情，还会继续发送消息broker接收不到数据就会数据丢失

ack:1

意味着producer要等待leader成功收到数据并得到确认，才发送下一条message。此选项提供了较好的持久性较低的延迟性。

Partition的Leader死亡，follwer尚未复制，数据就会丢失

ack:-1

producer等待broker的ackpartition的leader和follower全部落盘成功后，才会返回ack，但是如果follower同步完成之后，在broker发送ack之前，leader发生故障，那么会出现数据的重复，但不会造成数据丢失。

七、为什么要使用 kafka，为什么要使用消息队列？

缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。

解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。

冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。

健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。

异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

八、Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么？

ISR:In-Sync Replicas 副本同步队列

AR:Assigned Replicas 所有副本

ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度）。

任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

九、什么情况下一个 broker 会从 isr中踢出去？

leader会维护一个与其基本保持同步的Replica列表，该列表称为ISR(in-sync Replica)，每个Partition都会有一个ISR，而且是由leader动态维护 ，如果一个follower比一个leader落后太多，或者超过一定时间未发起数据复制请求，则leader将其重ISR中移除 。

十、kafka producer如何优化打入速度？

增加线程

提高 batch.size

增加更多 producer 实例

增加 partition 数

设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；

跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

十一、如果leader crash时，ISR为空怎么办？

kafka的leader副本选举

如果某个分区的Leader挂了,那么其它跟随者将会进行选举产生一个新的leader,之后所有的读写就会转移到这个新的Leader上。

在kafka中,其不是采用常见的多数选举的方式进行副本的Leader选举,而是会在Zookeeper上针对每个Topic维护一个称为ISR（in-sync replica，已同步的副本）的集合,显然还有一些副本没有来得及同步。只有这个ISR列表里面的才有资格成为leader(先使用ISR里面的第一个，如果不行依次类推，因为ISR里面的是同步副本，消息是最完整且各个节点都是一样的)。

通过ISR,kafka需要的冗余度较低，可以容忍的失败数比较高。假设某个topic有f+1个副本，kafka可以容忍f个不可用,当然,如果全部ISR里面的副本都不可用,也可以选择其他可用的副本,只是存在数据的不一致。

如果ISR为空

kafka在Broker端提供了一个配置参数：unclean.leader.election,这个参数有两个值：

true（默认）：允许不同步副本成为leader，由于不同步副本的消息较为滞后，此时成为leader，可能会出现消息不一致的情况。

false：不允许不同步副本成为leader，此时如果发生ISR列表为空，会一直等待旧leader恢复，降低了可用性。

十二、kafka follower如何与leader同步数据？

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。

完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。

而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据。

kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

十三、kafka 为什么那么快？

1、Cache Filesystem Cache PageCache缓存

Kafka使用了基于日志结构(log-structured)的数据格式，即每个分区日志只能在尾部追加写入(append)，而不允许随机“跳到”某个位置开始写入，故此实现了顺序写入。

顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。

2、Zero-copy 零拷技术减少拷贝次数

传统的读取文件数据并发送到网络的步骤如下：
（1）操作系统将数据从磁盘文件中读取到内核空间的页面缓存；
（2）应用程序将数据从内核空间读入用户空间缓冲区；
（3）应用程序将读到数据写回内核空间并放入socket缓冲区；
（4）操作系统将数据从socket缓冲区复制到网卡接口，此时数据才能通过网络发送。

Kafka使用了“零拷贝技术”，只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），避免了重复复制操作

参考：https://www.jianshu.com/p/835ec2d4c170

3、Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。

4、Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

十四、Kafka中是怎么体现消息顺序性的？

kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。

整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1.

十五、为什么Kafka不支持读写分离？

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型。

Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:

(1)数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。

(2)延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

十六、Kafka 判断一个节点是否还活着有那两个条件？

（1）节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连

接

（2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久

十七、Kafa consumer 是否可以消费指定分区消息？

Kafa consumer 消费消息时，向 broker 发出"fetch"请求去消费特定分区的消息，consumer

指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer 拥有

了 offset 的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的

十八、Kafka 创建 Topic 时如何将分区放置到不同的 Broker 中?

1、副本因子不能大于 Broker 的个数；

2、第一个分区（编号为 0）的第一个副本放置位置是随机从 brokerList 选择的；

3、其他分区的第一个副本放置位置相对于第 0 个分区依次往后移。也就是如果我们有 5 个

Broker，5 个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五

个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个

Broker 上，依次类推；

4、剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是

随机产生的

十九、partition 的数据如何保存到硬盘?

topic 中的多个 partition 以文件夹的形式保存到 broker，每个分区序号从 0 递增，

且消息有序

Partition 文件下有多个 segment（xxx.index，xxx.log）

segment 文件里的 大小和配置文件大小一致可以根据要求修改 默认为 1g

如果大于了 1g 时，会滚动一个新的 segment 并且以上一个 segment 最后一条消息的偏移

量命名

二十、Kafka 的消费者如何消费数据

消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（offset）的位置

等到下次消费时，他会接着上次位置继续消费

二十一、使用 MQ 的缺陷有哪些？

系统可用性降低：以前只要担心系统的问题，现在还要考虑 MQ 挂掉的问题，MQ 挂掉，所关联的系统都会无法提供服务。

系统复杂性变高：要考虑消息丢失、消息重复消费等问题。

一致性问题：多个 MQ 消费系统，部分成功，部分失败，要考虑事务问题。

二十二、你了解哪些常用的 MQ？

ActiveMQ：支持万级的吞吐量，较成熟完善；官方更新迭代较少，社区的活跃度不是很高，有消息丢失的情况。

RabbitMQ：延时低，微妙级延时，社区活跃度高，bug 修复及时，而且提供了很友善的后台界面；用 Erlang 语言开发，只熟悉 Java 的无法阅读源码和自行修复 bug。

RocketMQ：阿里维护的消息中间件，可以达到十万级的吞吐量，支持分布式事务。

Kafka：分布式的中间件，最大优点是其吞吐量高，一般运用于大数据系统的实时运算和日志采集的场景，功能简单，可靠性高，扩展性高；缺点是可能导致重复消费。

二十三、如何保证MQ的高可用?

ActiveMQ：

Master-Slave 部署方式主从热备，方式包括通过共享存储目录来实现(shared filesystem Master-Slave)、通过共享数据库来实现(shared database Master-Slave)、5.9版本后新特性使用 ZooKeeper 协调选择 master(Replicated LevelDB Store)。

Broker-Cluster 部署方式进行负载均衡。

RabbitMQ：

单机模式与普通集群模式无法满足高可用，镜像集群模式指定多个节点复制 queue 中的消息做到高可用，但消息之间的同步网络性能开销较大。

RocketMQ：

有多 master 多 slave 异步复制模式和多 master 多 slave 同步双写模式支持集群部署模式。

Producer 随机选择 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Master 发送心跳，只能将消息发送到 Broker master。

Consumer 同时与提供 Topic 服务的 Master、Slave 建立长连接，从 Master、Slave 订阅消息都可以，订阅规则由 Broker 配置决定。

Kafka：

由多个 broker 组成，每个 broker 是一个节点；topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 存放一部分数据，这样每个 topic 的数据就分散存放在多个机器上的。

replica 副本机制保证每个 partition 的数据同步到其他节点，形成多 replica 副本；所有 replica 副本会选举一个 leader 与 Producer、Consumer 交互，其他 replica 就是 follower；写入消息 leader 会把数据同步到所有 follower，从 leader 读取消息。

每个 partition 的所有 replica 分布在不同的机器上。某个 broker 宕机，它上面的 partition 在其他节点有副本，如果有 partition 的 leader，会进行重新选举 leader。

二十四、如何保证消息不被重复消费?

消息被重复消费，就是消费方多次接受到了同一条消息。根本原因就是，第一次消费完之后，消费方给 MQ 确认已消费的反馈，MQ 没有成功接受。比如网络原因、MQ 重启等。

所以 MQ 是无法保证消息不被重复消费的，只能业务系统层面考虑。

不被重复消费的问题，就被转化为消息消费的幂等性的问题。幂等性就是指一次和多次请求的结果一致，多次请求不会产生副作用。

保证消息消费的幂等性可以考虑下面的方式：

给消息生成全局 id，消费成功过的消息可以直接丢弃

消息中保存业务数据的主键字段，结合业务系统需求场景进行处理，避免多次插入、是否可以根据主键多次更新而并不影响结果等

二十五、消息大量积压怎么解决？

消息的积压来自于两方面：要么发送快了，要么消费变慢了。

单位时间发送的消息增多，比如赶上大促或者抢购，短时间内不太可能优化消费端的代码来提升消费性能，唯一的办法是通过扩容消费端的实例数来提升总体的消费能力。严重影响 QM 甚至整个系统时，可以考虑临时启用多个消费者，并发接受消息，持久化之后再单独处理，或者直接丢弃消息，回头让生产者重新生产。

如果短时间内没有服务器资源扩容，没办法的办法是将系统降级，通过关闭某些不重要的业务，减少发送的数据量，最低限度让系统还能正常运转，服务重要业务。

监控发现，产生和消费消息的速度没什么变化，出现消息积压的情况，检查是有消费失败反复消费的情况。

监控发现，消费消息的速度变慢，检查消费实例，日志中是否有大量消费错误、消费线程是否死锁、是否卡在某些资源上。