大数据之kafka

Kafka

旨在提供三大特性：

1.提供一套API实现生产者和消费者

2.降低网络传输和磁盘存储开销

3.实现高伸缩性架构

概述

定义

Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域

消息队列

MQ传统应用场景之异步处理

使用消息队列的好处

1）解耦

允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2）可恢复性

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所 以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

3）缓冲

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况

4）灵活性 & 峰值处理能力

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。 如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列 能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

5）异步通信

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

消息队列的两种模式

（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。 消息被消费以后，queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消息。 Queue 支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

（2）发布/订阅模式（一对多，消费者消费数据之后不会清除消息）

消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消 息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费

Kafka基础架构

1）Producer ：消息生产者，就是向 kafka broker 发消息的客户端；

2）Consumer ：消息消费者，向 kafka broker 取消息的客户端；

3）Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负 责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4）Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；

6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上， 一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；

7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失， 且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，

一个 leader 和若干个 follower。

8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对 象都是 leader。

9）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据 的同步。leader 发生故障时，某个 follower 会成为新的 follower。

Kafka-topic

1.副本因子不大于分区数量

2.分区的数量可以大于broker数量，但最好跟broker保持一致

3.不建议删除topic

生产

往主题中写入消息

kafka-console-producer.sh 

消费

从主题中消费消息

kafka-console-consumer.sh 

消费组

查看当前消费组，如果当前消费组相同则共享消费进度

kafka-consumer-groups.sh

分区策略

为什么分区：分区的作用就是提供生产消费数据负载分担的能力；不同的分区被分配在不同节点，数据的生产消费是基于分区粒度进行的，这样每个节点都能独立执行各自分区的数据生产消费，而且我们可以按照需要增加新的节点提升系统的吞吐量。

kafka提供三种分区策略：轮询、随机、按消息键保序

partition个数只能增加不能减少。

Kafka架构

replica：

每⼀个分区，根据副本因⼦N，会有N个副本。⽐如在broker1上有⼀个topic，分区为topic-1, 副本因⼦为2，那么在两个broker的数据⽬录⾥，就都有⼀个topic-1,其中⼀个是leader，⼀个follower。

Segment

partition 物理上由多个 segment 组成，每个 Segment 存着 message 信息。

Leader

每个partition有多个副本，其中有且仅有⼀个作为Leader，Leader是当前负责数据的读写的partition。

Follower

Follower跟随Leader，所有写请求都通过Leader路由，数据变更会⼴播给所有Follower，Follower与Leader保 持数据同步。如果Leader失效，则从Follower中选举出⼀个新的Leader。当Follower与Leader挂掉、卡住或者同 步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建⼀个Follower。

Offset

kafka的存储⽂件都是按照offset.log来命名，⽤offset做名字的好处是⽅便查找。例如你想找位于2049的位置，只要找到2048.log的⽂件即可。当然the first offset就是00000000000.log

ISR：副本同步列表

两个Leader

1.ControllerLeader 管理Broker上下线

2.PartitionLeader 通常说的是这个Leader (负责分区读写)

Partititon Follower :负责和Leader同步,作为候选Leader

分布式模型

每个分区都有leader和follower(不是必须)，即⽼⼤和⼩弟的⻆⾊，这⼉是⽼⼤负责处理，⼩弟负责同步，⼩弟可以变成⽼⼤，形成分布式模型

Kafka并发 （重点√）

kafka消费的并⾏度就是kaka topic分区的个数，或者分区的个数决定了同⼀时间同⼀消费者组内最多可以有多少个

消费者消费数据。

简单来说:topic的分区数量应该和消费组内的消费线程数量相同

多节点partition存储分布

分区副本分配策略

决定每个分区的副本(包含leader副本+follower副本)如何分配在Broker server上

验证:(单机)三个Kafka Broker

副本分配算法：

• 将所有N Broker和待分配的i个Partition排序。

• 将第i个Partition分配到第(i mod n)个Broker上。

**- 将第i个Partition的第j个副本分配到第((i + j) mod n)个Broker上。（j>=1）

数据分配策略

决定了数据如何进⼊哪个分区

1.实现org.apache.kafka.clients.producer.Partitioner接⼝

2.配置分区:

prop.put(“partitioner.class”,“com.desheng.bigdata.kafka.partitioner.RandomPartitioner”)

Kafka log（图）

Kafka log文件包括：1.index:索引

2.log:数据⽂件

⽂件名前缀是相同,⼀个log对应⼀个index⽂件,index⽂件是log⽂件的10%.初始是10MB 默认LOG是1GB,index

默认100MB

Kafka存储空间: 1KB * 1亿 =100,000,000KB=100GB

考虑索引⽂件 100*110%= 110GB

考虑副本数量 110GB*2=220GB

考虑压缩⽐ 220*75%=17=165GB

存储三个⽉数据:165GB*100= 16,500GB

Kafka需要多少节点:

考虑分区的数量:受限制于峰值流量 100万/次 Kafka单吞吐 10~100W 取10万 10个分区

索引⽂件存储⼤量元数据，数据⽂件存储⼤量消息，索引⽂件中元数据指向对应数据⽂件中message的物理偏移地址。

message物理结

⼀个segment data file由许多message组成，⼀个message物理结构具体如下：

kafka读写文件（重点）

kafka中数据发送保障（ACK机制）

为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后， 都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进⾏下⼀轮的发送，否 则重新发送数据。

1.KafkaProducer

1. kafka中数据发送保障 (ACK机制)

ack=0 \ 1 \ -1 默认是1

当ack=0时,producer不需要cluster的确认即表示发送成功

当ack=1时,producer需要Leader分区确认才算成功

当ack=-1时,producer需要所有分区副本确认才算成功

不论ack如何取值,数据重复和丢失的问题都是客观存在

2)ISR

为什么需要ISR?

当ack=-1时,Kafka采⽤的全部follower同步策略.但这种情况下⽆法防⽌某些副本宕机的情况,leader不可能⽆限等待这个follower,所以重新维护⼀个动态副本同步列表(ISR)

ISR的特点:

ReplicaManager(副本管理器)依据replica.lag.time.max.ms(允许副本落后的最⼤时间)参数决定固定副本是否 加⼊ISR. 只要存在ISR中的副本,肯定是和leader同步的.

Leader维护了⼀个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。如果follower⻓时间未向leader同步数据，则该follower将被 踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。Leader发⽣故障之后，就会从ISR中选举新的 leader

处理数据发送保障: 不丢失不重复+⼀致性

ack+hw+isr 都不能100%解决.

1.ack=0还是会丢失数据

2.isr当ack信号没有传达,还是会重复发送数据

终级⼤招:Kafka幂等写⼊可以保证同⼀分区数据不会重复

幂等写入机制

Exactly Once(⼀次正好)语义

对于某些⽐较重要的消息，我们需要保证exactly once语义，即保证每条消息被发送且仅被发送⼀次。

在0.11版本之后，Kafka引⼊了幂等性机制（idempotent），配合acks = -1时的at least once(最少⼀次)语义，

实现了producer到broker的exactly once语义。

idempotent + at least once = exactly once

使⽤时，只需将enable.idempotence属性设置为true(在⽣产者的位置)，kafka⾃动将acks属性设为-1。

ps:幂等性机制是什么意思,幂等简单说1的⼏次幂都等于1,也就是说⼀条消息⽆论发⼏次都只算⼀次,⽆论多少条消息但只实例化⼀次

kafka完成幂等性其实就是给消息添加了唯⼀ID, 这个ID的组成是PID(ProducerID)这样保证每⼀个Producer发送的时候是唯⼀的,还会为Producer中每条消息添加⼀个消息ID,也就是说当前Producer中⽣产的消息会加⼊Producer的ID和消息ID这样就能保证消息唯⼀了,这个消息发送到Kafka中的时候回暂时缓存ID,写⼊数据后没有收到ack,那么会从新发送这个消息,新消息过来的时候会和缓存中ID进⾏⽐较如果发现已经存在就不会再次接受了

补充

kafka如何保证数据不丢失

1.生产者数据的不丢失

kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到，其中状态有0,1，-1。

如果是同步模式：ack机制能够保证数据的不丢失，如果ack设置为0，风险很大，一般不建议设置为0。即使设置为1，也会随着leader宕机丢失数据。

producer.type=sync

request.required.acks=1

如果是异步模式：也会考虑ack的状态，除此之外，异步模式下的有个buffer，通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，有个选项是配置是否立即清空buffer。可以设置为-1，永久阻塞，也就数据不再生产。

异步模式下，即使设置为-1。也可能因为程序员的不科学操作，操作数据丢失，比如kill -9，但这是特别的例外情况。

producer.type=async

request.required.acks=1

queue.buffering.max.ms=5000

queue.buffering.max.messages=10000

queue.enqueue.timeout.ms = -1

batch.num.messages=200

结论：producer有丢数据的可能，但是可以通过配置保证消息的不丢失。

2.消费者数据的不丢失

通过offset commit 来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，会接着上次的offset进行消费。

而offset的信息在kafka0.8版本之前保存在zookeeper中，在0.8版本之后保存到topic中，即使消费者在运行过程中挂掉了，再次启动的时候会找到offset的值，找到之前消费消息的位置，接着消费，由于offset的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。

唯一例外的情况是，我们在程序中给原本做不同功能的两个consumer组设置KafkaSpoutConfig.bulider.setGroupid的时候设置成了一样的groupid，这种情况会导致这两个组共享同一份数据，就会产生组A消费partition1，partition2中的消息，组B消费partition3的消息，这样每个组消费的消息都会丢失，都是不完整的。 为了保证每个组都独享一份消息数据，groupid一定不要重复才行。

3.kafka集群中的broker的数据不丢失

每个broker中的partition我们一般都会设置有replication（副本）的个数，生产者写入的时候首先根据分发策略（有partition按partition，有key按key，都没有轮询）写入到leader中，follower（副本）再跟leader同步数据，这样有了备份，也可以保证消息数据的不丢失。

kafka如何保持数据

kafka 的分区多副本架构是kafka 可靠性保证的核心。能在消息写入多个副本得以是kafka崩溃时仍能保证消息的持久性。

设置kafka保存数据的时间 在 server.properties中配置 log.retention.minutes=1days log.cleanup.policy = delete Kafka定期为那些超过磁盘空间阈值的topic进行日志段的删除。这个阈值由broker端参数log.retention.bytes和topic级别参数retention.bytes控制，默认是-1，表示Kafka当前未开启这个留存机制，即不管topic日志量涨到多少，Kafka都不视其为“超过阈值”。如果用户要开启这种留存机制，必须显式设置log.retention.bytes（或retention.bytes）。 一旦用户设置了阈值，那么Kafka就会在定时任务中尝试比较当前日志量总大小是否超过阈值至少一个日志段的大小。这里所说的总大小是指所有日志段文件的大小，不包括索引文件的大小！如果是则会尝试从最老的日志段文件开始删起。注意这里的“超过阈值至少一个日志段的大小”，这就是说超过阈值的部分必须要大于一个日志段的大小，否则不会进行删除的，原因就是因为删除的标的是日志段文件——即文件只能被当做一个整体进行删除，无法删除部分内容。

kafka与其他主流大数据流式计算框架相比的优势

1.更容易实现端到端的正确性

2.基于kafka对于流式计算的定位

kafka快的原因

1.log有索引

2.log文件顺序写入（本地文件）

3.读取零copy技术，Nginx

4.批量

为什么要集成Flume和Kafka

1. 生产环境中，往往是读取日志进行分析，而这往往是多数据源的，如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便。
2. 如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。
3. Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。

ISR机制

Topic、Partition、Replica是主题层三要素，每个Topic都有至少一个Partition，而Partition有副本机制，Kafka 定义了两类副本：领导者副本和追随者副本。只能有 1 个领导者副本和 N-1 个追随者副本。

• 为什么kafka要有副本机制？
• 为什么要有领导者副本和追随者副本两种角色？
• 领导者副本和追随者副本之间的关系是什么？
• 当领导者副本挂了的时候，追随者副本会有怎样的操作？

副本优势

我们先不具体说kafka，而是广度的聊聊副本在分布式系统中，有什么优势？

首先你会毫不犹豫的说出：高可用性。这太容易理解了，就好像我们平时会把重要文件备份成两份放U盘一样。这样电脑万一被黑客入侵了，也不怕不怕啦。

分布式系统也是这么做的，通过提供数据冗余，即使系统部分组件失效，系统依然能够继续运转，增加了整体可用性以及数据持久性。

就这一个优势吗？显然不是的，你可能会联想到mysql的从库，mysql的从库可以帮助mysql抗压(抗读)，一切写的操作都在主库进行，而读的操作则分摊到从库进行，这样一来的可以大大提高读取的效率。

没错，分布式系统副本机制也提供了高伸缩性，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量。

但是，很遗憾，kafka没有这个优势，因为kafka的副本是不对外提供服务的。。

我们等会再来聊聊为啥它要这么小气，有数据还不给别人用呢！

反正现在你只需要记住，kafka的副本机制只有一个好处：就是通过数据冗余保证高可用性。

副本定义

你已经知道，partition的数据会有多个副本。那么这个副本，到底是个啥呢？其实不神秘，它就是一个只能追加写消息的提交日志。同一个分区下的所有副本保存有相同的消息序列，这些副本分散保存在不同的 Broker 上，从而能够对抗部分 Broker 宕机带来的数据不可用。

如图所示：TopicA有三个分区，part0、part1、part2。其中part0有两个副本，一个领导者副本和一个跟随者副本。分别在broker1和broker2上。

副本角色

为什么Kafka要定义两类副本：领导者副本（Leader Replica）和追随者副本（Follower Replica）。并且只能有 1 个领导者副本和 N-1 个追随者副本呢？

要回答这个问题，先思考下，既然分区下能够配置多个副本，而且这些副本的内容还要一致，那么我们该如何确保副本中所有的数据都是一致的呢？

首先，我们得有个基准吧，以谁的数据为准呢？不然公说公有理，婆说婆有理可不好了。所以，kafka才有了领导者的角色。

好了，我们以领导者的数据为准，即基于领导者（Leader-based）的副本机制，那么领导者负责与生产者交互，而追随者就拉取它的数据就好了，这样就很清晰了吧？如下图所示：

关于这张图，你重点理解下以下内容：

1、副本分成两类：领导者副本（Leader Replica）和追随者副本（Follower Replica）。每个分区在创建时都要选举一个副本，称为领导者副本，其余的副本自动称为追随者副本。

2、在 Kafka 中，追随者副本是不对外提供服务的。任何一个追随者副本都不能响应消费者和生产者的读写请求。所有的请求都必须由领导者副本来处理，或者说，所有的读写请求都必须发往领导者副本所在的 Broker，由该 Broker 负责处理。追随者副本不处理客户端请求，它唯一的任务就是从领导者副本异步拉取消息，并写入到自己的提交日志中，从而实现与领导者副本的同步。

3、当领导者副本挂掉了，Kafka 依托于 ZooKeeper 提供的监控功能能够实时感知到，并立即开启新一轮的领导者选举，从追随者副本中选一个作为新的领导者。老 Leader 副本重启回来后，只能作为追随者副本加入到集群中。

注意标红的字眼，追随者副本是不对外提供服务的。还记得刚刚我们谈到副本机制的好处时，说过 Kafka 没能提供读操作横向扩展吗？具体的原因就在于此。总而言之，kafka的追随者副本除了保证高可用，没其他好处了。对于客户端用户而言，它就是一文不值。

既然如此，Kafka 为什么要这样设计呢？其实这种副本机制有两个方面的好处。

1.方便实现“Read-your-writes”。

所谓 Read-your-writes，顾名思义就是，当你使用生产者 API 向 Kafka 成功写入消息后，马上使用消费者 API 去读取刚才生产的消息。

举个例子，比如你平时发微博时，你发完一条微博，肯定是希望能立即看到的，这就是典型的 Read-your-writes 场景。如果允许追随者副本对外提供服务，由于副本同步是异步的，因此有可能出现追随者副本还没有从领导者副本那里拉取到最新的消息，从而使得客户端看不到最新写入的消息。

2.方便实现单调读（Monotonic Reads）。

什么是单调读呢？就是对于一个消费者用户而言，在多次消费消息时，它不会看到某条消息一会儿存在一会儿不存在。

如果允许追随者副本提供读服务，那么假设当前有 2 个追随者副本 F1 和 F2，它们异步地拉取领导者副本数据。倘若 F1 拉取了 Leader 的最新消息而 F2 还未及时拉取，那么，此时如果有一个消费者先从 F1 读取消息之后又从 F2 拉取消息，它可能会看到这样的现象：第一次消费时看到的最新消息在第二次消费时不见了，这就不是单调读一致性。但是，如果所有的读请求都是由 Leader 来处理，那么 Kafka 就很容易实现单调读一致性。

Leader挂了怎么办？

刚刚我们反复强调，只有Leader副本才可提供服务。消费者和生产者的读写请求都是由Leader副本来完成的。

那么Leader挂了怎么办？不假思索就可以回答出：老大挂了老二上。可是老二要怎么上位？尤其在有很多Follow副本的时候，kafka应该如何选择？

也不难回答出，肯定是选择优质的备胎。

不是说所有副本都保存一样的消息吗？还怎么区分优质啊？

所有副本都一样，那只是在正常情况下。既然追随者只是定期地异步拉取领导者副本中的数据，异步的，就存在着不可能与 Leader 实时同步的风险。

默认情况下（注意只是默认），只有被认定为是实时同步的Follower副本，才可能被选举成Leader。

一个副本与 leader 失去实时同步的原因有很多，比如：

• 慢副本（Slow replica）：follower replica 在一段时间内一直无法赶上 leader 的写进度。造成这种情况的最常见原因之一是 follower replica 上的 I/O瓶颈，导致它持久化日志的时间比它从 leader 消费消息的时间要长；
• 卡住副本（Stuck replica）：follower replica 在很长一段时间内停止从 leader 获取消息。这可能是以为 GC 停顿，或者副本出现故障；

刚启动副本（Bootstrapping replica）：当用户给某个主题增加副本因子时，新的 follower replicas 是不同步的，直到它跟上 leader 的日志。

如果你是个细心的人，抠一下刚刚那几段话的字眼，

“在一段时间内一直无法赶上 leader 的写进度”

你会产生这样的疑问：一段时间到底是指多久呢？

比如我们知道小学生优秀的标准是80分，那么Follow副本，你要确认它是否优质，也得给个标准吧？

这个标准就是 Broker 端参数 replica.lag.time.max.ms 参数值。这个参数的含义是 Follower 副本能够落后 Leader 副本的最长时间间隔，当前默认值是 10 秒。这就是说，只要一个 Follower 副本落后 Leader 副本的时间不连续超过 10 秒，那么 Kafka 就认为该 Follower 副本与 Leader 是同步的。反之，当副本落后于 leader 分区时，这个副本被认为是不同步或滞后的。

说到这里，可以引出kafka中大名鼎鼎的一个名词，叫做ISR

In-sync Replicas（ISR）

ISR 中的副本都是与 Leader 同步的副本，相反，不在 ISR 中的追随者副本就被认为是与 Leader 不同步的。

不过首先要明确的是，Leader 副本天然就在 ISR 中。也就是说，ISR 不只是追随者副本集合，它必然包括 Leader 副本。甚至在某些情况下，ISR 只有 Leader 这一个副本。

至于怎么认定Follower是否同步，刚刚已经说过了，Broker 端参数 replica.lag.time.max.ms 参数值。

如果这个同步过程的速度持续慢于 Leader 副本的消息写入速度，那么在 replica.lag.time.max.ms 时间后，此 Follower 副本就会被认为是与 Leader 副本不同步的，因此不能再放入 ISR 中。此时，Kafka 会自动收缩 ISR 集合，将该副本“踢出”ISR。

值得注意的是，倘若该副本后面慢慢地追上了 Leader 的进度，那么它是能够重新被加回 ISR 的。这也表明，ISR 是一个动态调整的集合，而非静态不变的。

Unclean Leader Election

unclean领导者选举。再回去看看刚刚我们说Leader挂了怎么办，有句话重点标粗，”默认情况下（注意只是默认），只有被认定为是实时同步的Follower副本，才可能被选举成Leader”。

这是由Broker 端参数 unclean.leader.election.enable 控制的。默认为false，即只有被认定为是实时同步的Follower副本（在ISR中的），才可能被选举成Leader。如果你设置为true,则所有副本都可以被选举。

开启 Unclean 领导者选举可能会造成数据丢失，但好处是，它使得分区 Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性。反之，禁止 Unclean 领导者选举的好处在于维护了数据的一致性，避免了消息丢失，但牺牲了高可用性。

如果你听说过 CAP 理论的话，你一定知道，一个分布式系统通常只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）中的两个。显然，在这个问题上，Kafka 赋予你选择 C 或 A 的权利。

你可以根据你的实际业务场景决定是否开启 Unclean 领导者选举。不过，我强烈建议你不要开启它，毕竟我们还可以通过其他的方式来提升高可用性。如果为了这点儿高可用性的改善，牺牲了数据一致性，那就非常不值当了。

总结

1、kafka副本只有一个好处：保证高可用性。

2、副本其实就是只能追加写消息的提交日志，kafka中副本分为领导者副本和追随者副本。每个partition都只能有一个领导者副本和N-1追随者副本。

3、仅领导者副本对外提供服务，追随者副本唯一做的事情就是异步同步领导者副本的消息。

4、ISR是与Leader副本以及与Leader同步的Follower副本的集合，如何判断是否同步，是依据broker端参数replica.lag.time.max.ms

5、你可以自行选择unclean领导者选举，如果要保证高可用性，则设为true，允许不同步的Follower被选举，如果要保证一致性，则设为False。