移动网站建设条件,做网站的大骗子,萍乡建站公司,ui设计培训课程最近整体梳理之前用到的一些东西#xff0c;回顾Kafka的时候好多东西都忘记了#xff0c;把一些自己记的比较模糊并且感觉有用的东西整理一遍并且记忆一遍#xff0c;仅用于记录以备后续回顾
Kafka的哪些场景中使用了零拷贝 生产者发送消息#xff1a;在 Kafka 生产者发送…最近整体梳理之前用到的一些东西回顾Kafka的时候好多东西都忘记了把一些自己记的比较模糊并且感觉有用的东西整理一遍并且记忆一遍仅用于记录以备后续回顾
Kafka的哪些场景中使用了零拷贝 生产者发送消息在 Kafka 生产者发送消息时使用零拷贝技术可以避免将数据从用户空间复制到内核空间从而提高性能。具体来说在发送消息之前生产者将消息数据保存在内存缓冲区中然后将指向缓冲区的指针传递给 Kafka 客户端库客户端库再将指针传递给网络层最终将数据发送到 Kafka 服务器。在这个过程中数据在内存中只有一份副本避免了数据的复制从而提高了性能。 消费者接收消息在 Kafka 消费者接收消息时使用零拷贝技术可以避免将数据从内核空间复制到用户空间从而提高性能。具体来说在接收消息之前消费者会注册一个内存映射文件Memory-mapped file然后 Kafka 客户端库会将消息数据写入到这个内存映射文件中。消费者只需要读取这个内存映射文件中的数据就可以获取消息避免了数据的复制从而提高了性能。 消费者读取磁盘上的消息Kafka 中的消息默认存储在磁盘上消费者需要从磁盘上读取消息。使用零拷贝技术可以将磁盘上的消息直接映射到内存中而不需要将数据从磁盘复制到内存从而提高了性能。
总之Kafka 使用零拷贝技术来提高网络传输性能和磁盘读取性能在发送消息和接收消息等场景中都得到了广泛应用。
为什么Kafka不支持读写分离
在 Kafka 中生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的从 而实现的是一种主写主读的生产消费模型。
Kafka 并不支持主写从读因为主写从读有 2 个很明 显的缺点:
数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口这个时间 窗口会导致主从节点之间的数据不一致。某一时刻在主节点和从节点中 A 数据的值都为 X 之后将主节点中 A 的值修改为 Y那么在这个变更通知到从节点之前应用读取从节点中的 A 数据的值并不为最新的 Y由此便产生了数据不一致的问题。 延时问题。类似 Redis 这种组件数据从写入主节点到同步至从节点中的过程需要经历网络→主节点内存→网络→从节点内存这几个阶段整个过程会耗费一定的时间。而在 Kafka 中主从同步会比 Redis 更加耗时它需要经历网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘这几个阶段。对延时敏感的应用而言主写从读的功能并不太适用。
Kafka 如何保证高可用
Kafka 的基本架构组成是由多个 broker 组成一个集群每个 broker 是一个节点当创建一个 topic 时这个 topic 会被划分为多个 partition每个 partition 可以存在于不同的 broker 上每个 partition 只存放一部分数据。
这就是天然的分布式消息队列就是说一个 topic 的数据是分散放在多个机器上的每个机器就放一部分数据。
在 Kafka 0.8 版本之前是没有 HA 机制的当任何一个 broker 所在节点宕机了这个 broker 上的 partition 就无法提供读写服务所以这个版本之前Kafka 没有什么高可用性可言。
在 Kafka 0.8 以后提供了 HA 机制就是 replica 副本机制。每个 partition 上的数据都会同步到其它机器形成自己的多个 replica 副本。所有 replica 会选举一个 leader 出来消息的生产者和消费者都跟这个 leader 打交道其他 replica 作为 follower。写的时候leader 会负责把数据同步到所有 follower 上去读的时候就直接读 leader 上的数据即可。Kafka 负责均匀的将一个 partition 的所有 replica 分布在不同的机器上这样才可以提高容错性。
拥有了 replica 副本机制如果某个 broker 宕机了这个 broker 上的 partition 在其他机器上还存在副本。如果这个宕机的 broker 上面有某个 partition 的 leader那么此时会从其 follower 中重新选举一个新的 leader 出来这个新的 leader 会继续提供读写服务这就有达到了所谓的高可用性。
写数据的时候生产者只将数据写入 leader 节点leader 会将数据写入本地磁盘接着其他 follower 会主动从 leader 来拉取数据follower 同步好数据了就会发送 ack 给 leaderleader 收到所有 follower 的 ack 之后就会返回写成功的消息给生产者。
消费数据的时候消费者只会从 leader 节点去读取消息但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候这个消息才会被消费者读到。 什么是消费者组
消费者组是Kafka独有的概念即消费者组是Kafka提供的可扩展且具有容错性的消费者机制。
但实际上消费者组Consumer Group其实包含两个概念作为队列消费者组允许你分割数据处理到一组进程集合上即一个消费者组中可以包含多个消费者进程他们共同消费该topic的数据这有助于你的消费能力的动态调整作为发布-订阅模型publish-subscribeKafka允许你将同一份消息广播到多个消费者组里以此来丰富多种数据使用场景。
需要注意的是在消费者组中多个实例共同订阅若干个主题实现共同消费。同一个组下的每个实例都配置有相同的组ID被分配不同的订阅分区。当某个实例挂掉的时候其他实例会自动地承担起它负责消费的分区。 因此消费者组在一定程度上也保证了消费者程序的高可用性。
kafka 为什么那么快
Cache Filesystem Cache PageCache缓存顺序写由于现代的操作系统提供了预读和写技术磁盘的顺序写大多数情况下比随机写内存还要快。Zero-copy零拷技术减少拷贝次数Batching of Messages批量量处理。合并小的请求然后以流的方式进行交互直顶网络上限。Pull 拉模式使用拉模式进行消息的获取消费与消费端处理能力相符。
Kafka如何保证消息不丢失?
首先需要弄明白消息为什么会丢失对于一个消息队列会有 生产者、MQ、消费者 这三个角色在这三个角色数据处理和传输过程中都有可能会出现消息丢失。
消息丢失的原因以及解决办法
消费者异常导致的消息丢失
消费者可能导致数据丢失的情况是消费者获取到了这条消息后还未处理Kafka 就自动提交了 offset这时 Kafka 就认为消费者已经处理完这条消息其实消费者才刚准备处理这条消息这时如果消费者宕机那这条消息就丢失了。
消费者引起消息丢失的主要原因就是消息还未处理完 Kafka 会自动提交了 offset那么只要关闭自动提交 offset消费者在处理完之后手动提交 offset就可以保证消息不会丢失。但是此时需要注意重复消费问题比如消费者刚处理完还没提交 offset这时自己宕机了此时这条消息肯定会被重复消费一次这就需要消费者根据实际情况保证幂等性。
生产者数据传输导致的消息丢失
对于生产者数据传输导致的数据丢失主常见情况是生产者发送消息给 Kafka由于网络等原因导致消息丢失对于这种情况也是通过在 producer 端设置 acksall 来处理这个参数是要求 leader 接收到消息后需要等到所有的 follower 都同步到了消息之后才认为本次写成功了。如果没满足这个条件生产者会自动不断的重试。
Kafka 导致的消息丢失
Kafka 导致的数据丢失一个常见的场景就是 Kafka 某个 broker 宕机而这个节点正好是某个 partition 的 leader 节点这时需要重新重新选举该 partition 的 leader。如果该 partition 的 leader 在宕机时刚好还有些数据没有同步到 follower此时 leader 挂了在选举某个 follower 成 leader 之后就会丢失一部分数据。
对于这个问题Kafka 可以设置如下 4 个参数来尽量避免消息丢失
给 topic 设置 replication.factor 参数这个值必须大于 1要求每个 partition 必须有至少 2 个副本在 Kafka 服务端设置 min.insync.replicas 参数这个值必须大于 1这个参数的含义是一个 leader 至少感知到有至少一个 follower 还跟自己保持联系没掉队这样才能确保 leader 挂了还有一个 follower 节点。在 producer 端设置 acksall这个是要求每条数据必须是写入所有 replica 之后才能认为是写成功了在 producer 端设置 retriesMAX很大很大很大的一个值无限次重试的意思这个参数的含义是一旦写入失败就无限重试卡在这里了。
Kafka 如何保证消息的顺序性
在某些业务场景下我们需要保证对于有逻辑关联的多条MQ消息被按顺序处理比如对于某一条数据正常处理顺序是新增-更新-删除最终结果是数据被删除如果消息没有按序消费处理顺序可能是删除-新增-更新最终数据没有被删掉可能会产生一些逻辑错误。对于如何保证消息的顺序性主要需要考虑如下两点
如何保证消息在 Kafka 中顺序性如何保证消费者处理消费的顺序性。
如何保证消息在 Kafka 中顺序性
对于 Kafka如果我们创建了一个 topic默认有三个 partition。生产者在写数据的时候可以指定一个 key比如在订单 topic 中我们可以指定订单 id 作为 key那么相同订单 id 的数据一定会被分发到同一个 partition 中去而且这个 partition 中的数据一定是有顺序的。消费者从 partition 中取出来数据的时候也一定是有顺序的。通过制定 key 的方式首先可以保证在 kafka 内部消息是有序的。
如何保证消费者处理消费的顺序性
对于某个 topic 的一个 partition只能被同组内部的一个 consumer 消费如果这个 consumer 内部还是单线程处理那么其实只要保证消息在 MQ 内部是有顺序的就可以保证消费也是有顺序的。但是单线程吞吐量太低在处理大量 MQ 消息时我们一般会开启多线程消费机制那么如何保证消息在多个线程之间是被顺序处理的呢对于多线程消费我们可以预先设置 N 个内存 Queue具有相同 key 的数据都放到同一个内存 Queue 中然后开启 N 个线程每个线程分别消费一个内存 Queue 的数据即可这样就能保证顺序性。当然消息放到内存 Queue 中有可能还未被处理consumer 发生宕机内存 Queue 中的数据会全部丢失这就转变为上面提到的如何保证消息的可靠传输的问题了。
14. Kafka中的ISR、AR代表什么ISR的伸缩指什么
ISRIn-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存入OSROutof-Sync Replicas列表新加入的follower也会先存放在OSR中。 ARISROSR。 分区Leader选举策略有几种
分区的Leader副本选举对用户是完全透明的它是由Controller独立完成的。你需要回答的是在哪些场景下需要执行分区Leader选举。每一种场景对应于一种选举策略。
OfflinePartition Leader选举每当有分区上线时就需要执行Leader选举。所谓的分区上线可能是创建了新分区也可能是之前的下线分区重新上线。这是最常见的分区Leader选举场景。ReassignPartition Leader选举当你手动运行kafka-reassign-partitions命令或者是调用Admin的alterPartitionReassignments方法执行分区副本重分配时可能触发此类选举。假设原来的AR是[123]Leader是1当执行副本重分配后副本集合AR被设置成[456]显然Leader必须要变更此时会发生Reassign Partition Leader选举。PreferredReplicaPartition Leader选举当你手动运行kafka-preferred-replica-election命令或自动触发了Preferred Leader选举时该类策略被激活。所谓的Preferred Leader指的是AR中的第一个副本。比如AR是[321]那么Preferred Leader就是3。ControlledShutdownPartition Leader选举当Broker正常关闭时该Broker上的所有Leader副本都会下线因此需要为受影响的分区执行相应的Leader选举。
这4类选举策略的大致思想是类似的即从AR中挑选首个在ISR中的副本作为新Leader。
