springboot集成kafka
目录
1、kafka的消费者是pull(拉)还是push(推)模式，这种模式有什么好处？
kafka 如何不消费重复数据？比如扣款，我们不能重复的扣。
6、kafka 分布式（不是单机）的情况下，如何保证消息的顺序消费?
10、partition的数据文件（offffset，MessageSize，data）
11、kafka如何实现数据的高效读取？（顺序读写、分段命令、二分查找）
12、 Kafka 消费者端的 Rebalance 操作什么时候发生？
13、Kafka 中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)代表什么？
1、kafka的消费者是pull(拉)还是push(推)模式，这种模式有什么好处？
producer 将消息推送到 broker，consumer 从broker 拉取消息。
一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式，将消息推送到下游的 consumer。这样做有好处也有坏处：由 broker 决定消息推送的速率，对于不同消费速率的 consumer 就不太好处理了。消息系统都致力于让 consumer 以最大的速率最快速的消费消息，但不幸的是，push 模式下，当 broker 推送的速率远大于 consumer 消费的速率时，consumer 恐怕就要崩溃了。最终 Kafka 还是选取了传统的 pull 模式。
优点： Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据。Push 模式必须在不知道下游 consumer 消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免 consumer 崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull 模式下，consumer 就可以根据自己的消费能力去决定这些策略。
缺点： 如果 broker 没有可供消费的消息，将导致 consumer 不断在循环中轮询，直到新消息到达。为了避免这点，Kafka 有个参数可以让 consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发送)。
Kafka高性能原因
1. 分区
生产者往Kafka发送消息时必须指定发往哪个主题，消费者需要订阅某个主题才能进行消费。一个主题下的分区可以分布在集群的不同broker上面，也就是说，一个主题可以横跨多个broker。这样的话，生产者在指定主题（可以指定也可以不指定分区）发送消息的时候，Kafka会将消息分发至不同的分区，如果这些分区不在同一个broker上，就相当于并发的写入多台broker，性能自然要比写入单台broker要高。对于消费者，Kafka引入了消费组(Consumer Group)的概念，每个消费者都有一个对应的消费组。一个分区只能被一个消费组中的一个消费者消费，但是可以被不同消费组中的另一个消费者消费。可以在一个消费组里起多个消费者，每个消费者消费一个分区，这样就提高了消费者的性能。需要注意的是，消费组里的消费者个数如果多于分区数的话，那些多出来的消费者就会处于空闲状态，所以一个消费组里的消费者个数跟分区数相等就好了。下图展示了消费者组与分区的关系。
分区的设计使得Kafka消息的读写性能可以突破单台broker的I/O性能瓶颈，可以在创建主题的时候指定分区数，也可以在主题创建完成之后去修改分区数，通过增加分区数可以实现水平扩展，但是要注意，分区数也不是越多越好，一般达到某一个阈值之后，再增加分区数性能反而会下降，具体阈值需要对Kafka集群进行压测才能确定。
2. 日志分段存储
为了防止日志（Log）过大，Kafka引入了日志分段（LogSegment）的概念，将日志切分成多个日志分段。在磁盘上，日志是一个目录，每个日志分段对应于日志目录下的日志文件、偏移量索引文件、时间戳索引文件（可能还有其他文件）。
向日志中追加消息是顺序写入的，只有最后一个日志分段才能执行写入操作，之前所有的日志分段都不能写入数据。
为了便于检索，每个日志分段都有两个索引文件：偏移量索引文件和时间戳索引文件。每个日志分段都有一个基准偏移量baseOffset，用来表示当前日志分段中第一条消息的offset。偏移量索引文件和时间戳索引文件是以稀疏索引的方式构造的，偏移量索引文件中的偏移量和时间戳索引文件中的时间戳都是严格单调递增的。查询指定偏移量（或时间戳）时，使用二分查找快速定位到偏移量（或时间戳）的位置。可见Kafka中对消息的查找速度还是非常快的。
3. 消息顺序追加
Kafka是通过文件追加的方式来写入消息的，只能在日志文件的最后追加新的消息，并且不允许修改已经写入的消息，这种方式就是顺序写磁盘，而顺序写磁盘的速度是非常快的。
4. 页缓存
页缓存是操作系统实现的一种主要的磁盘缓存，以此用来减少对磁盘I/O的操作。具体来说，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问。
Kafka中大量使用了页缓存，消息都是先被写入页缓存，再由操作系统负责具体的刷盘任务（Kafka中也提供了同步刷盘和间断性强制算盘的功能）。
5. 零拷贝
零拷贝技术是一种避免CPU将数据从一块存储拷贝到另一块存储的技术。Kafka使用零拷贝技术将数据直接从磁盘复制到网卡设备缓冲区中，而不需要经过应用程序的转发。
通常应用程序将磁盘上的数据传送至网卡需要经过4步：
1. 调用read()，将数据从磁盘复制到内核模式的缓冲区；
2. CPU会将数据从内核模式复制到用户模式下的缓冲区；
3. 调用write()，将数据从用户模式下复制到内核模式下的Socket缓冲区；
4. 将数据从内核模式的Socket缓冲区复制到网卡设备。
Kafka 如何保证消息可靠性
1 生产者发送消息丢失
kafka支持3种方式发送消息，这也是常规的3种方式，发送后不管结果、同步发送、异步发送，基本上所有的消息队列都是这样玩的。
发送并忘记，直接调用发送send方法，不管结果，虽然可以开启自动重试，但是肯定会有消息丢失的可能同步发送，同步发送返回Future对象，我们可以知道发送结果，然后进行处理
异步发送，发送消息，同时指定一个回调函数，根据结果进行相应的处理
为了保险起见，一般我们都会使用异步发送带有回调的方式进行发送消息，再设置参数为发送消息失败不停地重试。
acks=all，这个参数有可以配置0|1|all。
0表示生产者写入消息不管服务器的响应，可能消息还在网络缓冲区，服务器根本没有收到消息，当然会丢失消息。
1表示至少有一个副本收到消息才认为成功，一个副本那肯定就是集群的Leader副本了，但是如果刚好Leader副本所在的节点挂了，Follower没有同步这条消息，消息仍然丢失了。
配置all的话表示所有ISR都写入成功才算成功，那除非所有ISR里的副本全挂了，消息才会丢失。
retries=N，设置一个非常大的值，可以让生产者发送消息失败后不停重试
2 kafka broker 自身消息丢失
kafka因为消息写入是通过PageCache异步写入磁盘的，因此仍然存在丢失消息的可能。
因此针对kafka自身丢失的可能设置参数：
replication.factor=N，设置一个比较大的值，保证至少有2个或者以上的副本。
min.insync.replicas=N，代表消息如何才能被认为是写入成功，设置大于1的数，保证至少写入1个或者以上的副本才算写入消息成功。
unclean.leader.election.enable=false，这个设置意味着没有完全同步的分区副本不能成为Leader副本，如果是true的话，那些没有完全同步Leader的副本成为Leader之后，就会有消息丢失的风险。
3 消费者消息丢失
消费者丢失的可能就比较简单，关闭自动提交位移即可，改为业务处理成功手动提交。
因为重平衡发生的时候，消费者会去读取上一次提交的偏移量，自动提交默认是每5秒一次，这会导致重复消费或者丢失消息。
enable.auto.commit=false，设置为手动提交。
还有一个参数我们可能也需要考虑进去的：
auto.offset.reset=earliest，这个参数代表没有偏移量可以提交或者broker上不存在偏移量的时候，消费者如何处理。earliest代表从分区的开始位置读取，可能会重复读取消息，但是不会丢失，消费方一般我们肯定要自己保证幂等，另外一种latest表示从分区末尾读取，那就会有概率丢失消息。
kafka 如何不消费重复数据？比如扣款，我们不能重复的扣。
其实还是得结合业务来思考，我这里给几个思路：
比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。
比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。
比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据
消息队列有几百万消息持续积压几小时怎么解决？
先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉。
新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。
2、kafka维护消息状态的跟踪方法
Kafka中的Topic 被分成了若干分区，每个分区在同一时间只被一个 consumer 消费。然后再通过offset进行消息位置标记，通过位置偏移来跟踪消费状态。相比其他一些消息队列使用“一个消息被分发到consumer 后 broker 就马上进行标记或者等待 customer 的通知后进行标记”的优点是，避免了通信消息发送后，可能出现的程序奔溃而出现消息丢失或者重复消费的情况。同时也无需维护消息的状态，不用加锁，提高了吞吐量。
3、zookeeper对于kafka的作用是什么?
Zookeeper 主要用于在集群中不同节点之间进行通信，在 Kafka 中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取，除此之外，它还执行其他活动，如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
4、kafka判断一个节点还活着的有那两个条件？
（1）节点必须维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
（2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久
5、讲一讲 kafka 的 ack 的三种机制
request.required.acks 有三个值 0 1 -1(all)，具体如下：
0：生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据。
1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。
-1(all)：服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack，这样数据不会丢失。
6、kafka 分布式（不是单机）的情况下，如何保证消息的顺序消费?
Kafka 中发送 1 条消息的时候，可以指定(topic, partition, key) 3 个参数，partiton 和 key 是可选的。
Kafka 分布式的单位是 partition，同一个 partition 用一个 write ahead log 组织，所以可以保证FIFO 的顺序。不同 partition 之间不能保证顺序。因此你可以指定 partition，将相应的消息发往同 1个 partition，并且在消费端，Kafka 保证1 个 partition 只能被1 个 consumer 消费，就可以实现这些消息的顺序消费。
另外，你也可以指定 key（比如 order id），具有同 1 个 key 的所有消息，会发往同 1 个partition，那这样也实现了消息的顺序消息。
8、讲一下kafka集群的组成？
kafka的集群图如下：
Broker（代理）
Kafka集群通常由多个代理组成以保持负载平衡。 Kafka代理是无状态的，所以他们使用ZooKeeper来维护它们的集群状态。 一个Kafka代理实例可以每秒处理数十万次读取和写入，每个Broker可以处理TB的消息，而没有性能影响。 Kafka经纪人领导选举可以由ZooKeeper完成。
ZooKeeper
ZooKeeper用于管理和协调Kafka代理。 ZooKeeper服务主要用于通知生产者和消费者Kafka系统中存在任何新代理或Kafka系统中代理失败。 根据Zookeeper接收到关于代理的存在或失败的通知，然后生产者和消费者采取决定并开始与某些其他代理协调他们的任务。
Producers（生产者）
生产者将数据推送给经纪人。 当新代理启动时，所有生产者搜索它并自动向该新代理发送消息。 Kafka生产者不等待来自代理的确认，并且发送消息的速度与代理可以处理的一样快。
Consumers（消费者）
因为Kafka代理是无状态的，这意味着消费者必须通过使用分区偏移来维护已经消耗了多少消息。 如果消费者确认特定的消息偏移，则意味着消费者已经消费了所有先前的消息。 消费者向代理发出异步拉取请求，以具有准备好消耗的字节缓冲区。 消费者可以简单地通过提供偏移值来快退或跳到分区中的任何点。 消费者偏移值由ZooKeeper通知。
9、kafka是什么？
Kafka是一种高吞吐量、分布式、基于发布/订阅的消息系统，最初由LinkedIn公司开发，使用Scala语言编写，目前是Apache的开源项目。
broker： Kafka服务器，负责消息存储和转发
topic：消息类别，Kafka按照topic来分类消息
partition： topic的分区，一个topic可以包含多个partition， topic 消息保存在各个partition上4. offset：消息在日志中的位置，可以理解是消息在partition上的偏移量，也是代表该消息的唯一序号
Producer：消息生产者
Consumer：消息消费者
Consumer Group：消费者分组，每个Consumer必须属于一个group
Zookeeper：保存着集群 broker、 topic、 partition等meta 数据；另外，还负责broker故障发现， partition leader选举，负载均衡等功能
10、partition的数据文件（offffset，MessageSize，data）
partition中的每条Message包含了以下三个属性： offset，MessageSize，data，其中offset表示Message在这个partition中的偏移量，offset不是该Message在partition数据文件中的实际存储位置，而是逻辑上一个值，它唯一确定了partition中的一条Message，可以认为offset是partition中Message的 id； MessageSize表示消息内容data的大小；data为Message的具体内容。
11、kafka如何实现数据的高效读取？（顺序读写、分段命令、二分查找）
Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为index。 index文件中并没有为数据文件中的每条Message建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。
12、 Kafka 消费者端的 Rebalance 操作什么时候发生？
- 同一个 consumer 消费者组 group.id 中，新增了消费者进来，会执行 Rebalance 操作
- 消费者离开当期所属的 consumer group组。比如宕机
- 分区数量发生变化时(即 topic 的分区数量发生变化时)
- 消费者主动取消订阅
Rebalance的过程如下：
第一步：所有成员都向coordinator发送请求，请求入组。一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。
第二步：leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案发给coordinator。coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。
所以对于Rebalance来说，Coordinator起着至关重要的作用
13、Kafka 中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)代表什么？
答：kafka中与leader副本保持一定同步程度的副本（包括leader）组成ISR。与leader滞后太多的副本组成OSR。分区中所有的副本通称为AR。
ISR : 速率和leader相差低于10秒的follower的集合
OSR : 速率和leader相差大于10秒的follower
AR : 全部分区的follower
14、Kafka 中的HW、LEO等分别代表什么？
答：HW：高水位，指消费者只能拉取到这个offset之前的数据
LEO：标识当前日志文件中下一条待写入的消息的offset，大小等于当前日志文件最后一条消息的offset+1.
15、Kafka的那些设计让它有如此高的性能?
1.kafka是分布式的消息队列
2.对log文件进行了segment,并对segment创建了索引
3.(对于单节点)使用了顺序读写,速度能够达到600M/s
4.引用了zero拷贝,在os系统就完成了读写操做
16、Kafka为什么不支持读写分离？
- 这其实是分布式场景下的通用问题，因为我们知道CAP理论下，我们只能保证C（一致性）和A（可用性）取其一，如果支持读写分离，那其实对于一致性的要求可能就会有一定折扣，因为通常的场景下，副本之间都是通过同步来实现副本数据一致的，那同步过程中肯定会有时间的消耗，如果支持了读写分离，就意味着可能的数据不一致，或数据滞后。
- Leader/Follower模型并没有规定Follower副本不可以对外提供读服务。很多框架都是允许这么做的，只是 Kafka最初为了避免不一致性的问题，而采用了让Leader统一提供服务的方式。
- 不过，自Kafka 2.4之后，Kafka提供了有限度的读写分离，也就是说，Follower副本能够对外提供读服务。
17、分区Leader选举策略有几种？
1、 OfflinePartition Leader选举：每当有分区上线时，就需要执行Leader选举。所谓的分区上线，可能是创建了新分区，也可能是之前的下线分区重新上线。这是最常见的分区Leader选举场景。
2、 ReassignPartition Leader选举：当你手动运行Kafka-reassign-partitions命令，或者是调用Admin的alterPartitionReassignments方法执行分区副本重分配时，可能触发此类选举。假设原来的AR是[1，2，3]，Leader是1，当执行副本重分配后，副本集合AR被设置成[4，5，6]，显然，Leader必须要变更，此时会发生Reassign Partition Leader选举。
3、 PreferredReplicaPartition Leader选举：当你手动运行Kafka-preferred-replica-election命令，或自动触发了Preferred Leader选举时，该类策略被激活。所谓的Preferred Leader，指的是AR中的第一个副本。比如AR是[3，2，1]，那么，Preferred Leader就是3。
4、 ControlledShutdownPartition Leader选举：当Broker正常关闭时，该Broker上的所有Leader副本都会下线，因此，需要为受影响的分区执行相应的Leader选举。
这4类选举策略的大致思想是类似的，即从AR中挑选首个在ISR中的副本，作为新Leader。
18、请简述下你在哪些场景下会选择 Kafka？
•日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、HBase、Solr等。
•消息系统：解耦和生产者和消费者、缓存消息等。
•用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
•运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
•流式处理：比如spark streaming和 Flink
19、请谈一谈 Kafka 数据一致性原理
一致性就是说不论是老的 Leader 还是新选举的 Leader，Consumer 都能读到一样的数据。
假设分区的副本为3，其中副本0是 Leader，副本1和副本2是 follower，并且在 ISR 列表里面。虽然副本0已经写入了 Message4，但是 Consumer 只能读取到 Message2。因为所有的 ISR 都同步了 Message2，只有 High Water Mark 以上的消息才支持 Consumer 读取，而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区，对应于上图的副本2，这个很类似于木桶原理。
这样做的原因是还没有被足够多副本复制的消息被认为是“不安全”的，如果 Leader 发生崩溃，另一个副本成为新 Leader，那么这些消息很可能丢失了。如果我们允许消费者读取这些消息，可能就会破坏一致性。试想，一个消费者从当前 Leader（副本0） 读取并处理了 Message4，这个时候 Leader 挂掉了，选举了副本1为新的 Leader，这时候另一个消费者再去从新的 Leader 读取消息，发现这个消息其实并不存在，这就导致了数据不一致性问题。
当然，引入了 High Water Mark 机制，会导致 Broker 间的消息复制因为某些原因变慢，那么消息到达消费者的时间也会随之变长（因为我们会先等待消息复制完毕）。延迟时间可以通过参数 replica.lag.time.max.ms 参数配置，它指定了副本在复制消息时可被允许的最大延迟时间。
20、Kafka 缺点？
由于是批量发送，数据并非真正的实时；
•对于mqtt协议不支持；
•不支持物联网传感数据直接接入；
•仅支持统一分区内消息有序，无法实现全局消息有序；
•监控不完善，需要安装插件；
•依赖zookeeper进行元数据管理；
扫一扫
685
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
