郑州seo建站,宁波五金网站建设,设计公司工作室创业规划,宁波规划建设局网站目录
前言 副本定义
副本角色 In-sync Replicas#xff08;ISR#xff09;
参考资料 前言
现在的很多的分布式系统都支持副本的机制#xff0c;比如Mysql就有副本的机制#xff0c;一般使用副本有如下特性和好处。
提供数据冗余。即使系统部分组件失效#xff0c;系…目录
前言 副本定义
副本角色 In-sync ReplicasISR
参考资料 前言
现在的很多的分布式系统都支持副本的机制比如Mysql就有副本的机制一般使用副本有如下特性和好处。
提供数据冗余。即使系统部分组件失效系统依然能够继续运转因而增加了整体可用性以及数据持久性。提供高伸缩性。支持横向扩展能够通过增加机器的方式来提升读性能进而提高读操作吞吐量。改善数据局部性。允许将数据放入与用户地理位置相近的地方从而降低系统延时。
而kafka的副本机制仅仅享受到了第一个好处。但是即使是这样kafka的副本机制也是确保系统高可用和消息高持久性的重要基石。 副本定义
Kafka 是有主题概念的而每个主题又进一步划分成若干个分区。副本的概念实际上是在分区层级下定义的每个分区配置有若干个副本。
所谓副本Replica本质就是一个只能追加写消息的提交日志。根据 Kafka 副本机制的定义同一个分区下的所有副本保存有相同的消息序列这些副本分散保存在不同的 Broker 上从而能够对抗部分 Broker 宕机带来的数据不可用。
在实际生产环境中每台 Broker 都可能保存有各个主题下不同分区的不同副本因此单个 Broker 上存有成百上千个副本的现象是非常正常的。
示例图如下 副本角色 既然分区下能够配置多个副本而且这些副本的内容还要一致那么很自然的一个问题就是我们该如何确保副本中所有的数据都是一致的呢特别是对 Kafka 而言当生产者发送消息到某个主题后消息是如何同步到对应的所有副本中的呢针对这个问题最常见的解决方案就是采用基于领导者Leader-based的副本机制。
副本机制的工作原理图如下 第一在 Kafka 中副本分成两类领导者副本Leader Replica和追随者副本Follower Replica。每个分区在创建时都要选举一个副本称为领导者副本其余的副本自动称为追随者副本。
第二Kafka 的副本机制比其他分布式系统要更严格一些。在 Kafka 中追随者副本是不对外提供服务的。这就是说任何一个追随者副本都不能响应消费者和生产者的读写请求。所有的请求都必须由领导者副本来处理或者说所有的读写请求都必须发往领导者副本所在的 Broker由该 Broker 负责处理。追随者副本不处理客户端请求它唯一的任务就是从领导者副本异步拉取消息并写入到自己的提交日志中从而实现与领导者副本的同步。
第三当领导者副本挂掉了或者说领导者副本所在的 Broker 宕机时Kafka 依托于 ZooKeeper 提供的监控功能能够实时感知到并立即开启新一轮的领导者选举从追随者副本中选一个作为新的领导者。老 Leader 副本重启回来后只能作为追随者副本加入到集群中。 既然如此Kafka 为什么要这样设计呢其实这种副本机制有两个方面的好处。
1、方便实现“read your writes”
所谓 Read-your-writes顾名思义就是当你使用生产者 API 向 Kafka 成功写入消息后马上使用消费者 API 去读取刚才生产的消息。
2、方便实现单调读Monotonic Reads 什么是单调读呢就是对于一个消费者用户而言在多次消费消息时它不会看到某条消息一会儿存在一会儿不存在。 In-sync ReplicasISR Kafka 引入了 In-sync Replicas也就是所谓的 ISR 副本集合。ISR 中的副本都是与 Leader 同步的副本相反不在 ISR 中的追随者副本就被认为是与 Leader 不同步的。那么到底什么副本能够进入到 ISR 中呢
我们首先要明确的是Leader 副本天然就在 ISR 中。也就是说ISR 不只是追随者副本集合它必然包括 Leader 副本。甚至在某些情况下ISR 只有 Leader 这一个副本。 Broker 端参数 replica.lag.time.max.ms 参数值。这个参数的含义是 Follower 副本能够落后 Leader 副本的最长时间间隔当前默认值是 10 秒。这就是说只要一个 Follower 副本落后 Leader 副本的时间不连续超过 10 秒那么 Kafka 就认为该 Follower 副本与 Leader 是同步的即使此时 Follower 副本中保存的消息明显少于 Leader 副本中的消息。
Kafka 把所有不在 ISR 中的存活副本都称为非同步副本。通常来说非同步副本落后 Leader 太多因此如果选择这些副本作为新 Leader就可能出现数据的丢失。毕竟这些副本中保存的消息远远落后于老 Leader 中的消息。在 Kafka 中选举这种副本的过程称为 Unclean 领导者选举。Broker 端参数 unclean.leader.election.enable 控制是否允许 Unclean 领导者选举。
如果你听说过 CAP 理论的话你一定知道一个分布式系统通常只能同时满足一致性Consistency、可用性Availability、分区容错性Partition tolerance中的两个。显然在这个问题上Kafka 赋予你选择 C 或 A 的权利。
强烈建议你不要开启它毕竟我们还可以通过其他的方式来提升高可用性。如果为了这点儿高可用性的改善牺牲了数据一致性那就非常不值当了。
参考资料
23 | Kafka副本机制详解-极客时间
