二手房地产中介网站建设,标题制作网站,杭州免费网站建站模板,济南做网站个人Kafka 的副本机制
Kafka 的高可用实现主要依赖副本机制。
Broker 和 Partition 的关系
在分析副本机制之前#xff0c;先来看一下 Broker 和 Partition 之间的关系。Broker 在英文中是代理、经纪人的意思#xff0c;对应到 Kafka 集群中#xff0c;是一个 Kafka 服务器节…Kafka 的副本机制
Kafka 的高可用实现主要依赖副本机制。
Broker 和 Partition 的关系
在分析副本机制之前先来看一下 Broker 和 Partition 之间的关系。Broker 在英文中是代理、经纪人的意思对应到 Kafka 集群中是一个 Kafka 服务器节点Kafka 集群由多个 Broker 组成也就是对应多个 Kafka 节点。
Kafka 是典型的发布订阅模式存在 Topic 的概念一个 Broker 可以容纳多个 Topic也就是一台服务器可以传输多个 Topic 数据。
不过 Topic 是一个逻辑概念和物理上如何存储无关Kafka 为了实现可扩展性将一个 Topic 分散到多个 Partition 中这里的 Partition 就是一个物理概念对应的是具体某个 Broker 上的磁盘文件。
从 Partition 的角度Kafka 保证消息在 Partition 内部有序所以 Partition 是一段连续的存储不能跨多个 Broker 存在如果是在同一个 Broker 上也不能挂载到多个磁盘。从 Broker 的角度一个 Broker 可以有多个 Topic对应多个 Partition。
除此之外Partition 还可以细分为一个或者多个 Segment也就是数据块每个 Segment 都对应一个 index 索引文件以及一个 log 数据文件。对 Partition 的进一步拆分使得 Kafka 对 分区的管理更加灵活。
Replication副本 之间如何同步数据
基于 Kafka 的系统设计你可以思考一下如果没有副本那么当某个 Kafka Broker 挂掉或者某台服务器宕机可能部署了多个 Broker存储在其上的消息就不能被正常消费导致系统可用性降低或者出现数据丢失这不符合分布式高可用的要求出现单点故障也不满足 Kafka 数据传输持久性和投递语义的设计目标。
Kafka 中有一个配置参数 replication-factor副本因子可以调整对应分区下副本的数量注意副本因子数包含原来的 Partition如果需要有 2 个副本则要配置为 3。
假设现在有一个订单的 Topic配置分区数为 3如果配置 replication-factor 为 3那么对应的有三个分区每个分区都有 3 个副本。
在有多个副本的情况下不同副本之间如何分工呢
每个分区下配置多个副本多个副本之间为了协调就必须有一定的同步机制。
Kafka 中同一个分区下的不同副本有不同的角色关系分为 Leader Replication 和 Follower Replication。
Leader 负责处理所有 Producer、Consumer 的请求进行读写处理Follower 作为数据备份不处理来自客户端的请求。
Follower 不接受读写请求那么数据来自哪里呢
它会通过 Fetch Request 方式拉取 Leader 副本的数据进行同步。
Fetch 在 Kafka 中会为数据同步开辟一个单独的线程称为 ReplicaFetcherThread该线程会主动从 Leader 批量拉取数据这样可以高性能的实现数据同步。
Replication 分配有哪些约定
Kafka 中分区副本数的配置既要考虑提高系统可用性又要尽量减少机器资源浪费。
一方面为了更好地做负载均衡Kafka 会将所有的 Partition 均匀地分配到整个集群上
另一方面为了提高 Kafka 的系统容错能力一个 Partition 的副本也要分散到不同的 Broker 上否则就去了副本的意义。
一般来说为了尽可能地提升服务的可用性和容错率Kafka 的分区和副本分配遵循如下的原则
一个 Topic 的 Partition 数量大于 Broker 的数量使 Partition 尽量均匀分配到整个集群上同一个分区所有的副本要尽量均匀分配到集群中的多台 Broker 上尽可能保证同一个 分区下的主从副本分配到不同的 Broker 上。
Leader Replication 如何选举
一旦牵扯到数据同步就必然会有 Leader 节点宕机以后重新选择的问题。引入 Replication 机制之后同一个 Partition 可能会有多个副本如果Leader挂掉需要在这些副本之间选出一个 新的Leader。
Kafka 数据同步中有一个 ISRIn-Sync Replicas副本同步队列的概念Leader 节点在返回 ACK 响应时会关注 ISR 中节点的同步状态所以这个队列里的所有副本都和 Leader 保持一致。
Kafka 的 ISR 依赖 ZooKeeper 进行管理ISR 副本同步队列中的节点拥有优先选举的权利因为 ISR 里的节点和 Leader 保持一致如果必须满足一致性只有 ISR 里的成员才能被选为 Leader。
如果某个 Broker 挂掉Kafka 会从 ISR 列表中选择一个分区作为新的 Leader 副本。
如果 ISR 列表是空的这时候有两个策略一个是直接抛出 NoReplicaOnlineException 异常保证一致性另外一个是从其他副本中选择一个作为 Leader则可能会丢失数据具体需要根据业务场景进行配置。
所有的副本都挂了怎么办
现在考虑一个极端情况如果一个分区下的所有副本都挂掉了那如何处理呢
在这种情况下Kafka 需要等待某个副本恢复服务具体可以有两种方案 等待 ISR 中的某个副本恢复正常作为新的 Leader 方案一优先保证数据一致性 等待任一个 副本恢复正常作为新的 Leader。 方案二优先保证服务可用性
在第二种方案下由于选择的 Leader 节点可能不是来自 ISR所以可能会存在数据丢失不能保证已经包含全部 Commit 的信息 如果选择第一种方案会保证数据不丢失但是如果全部的 ISR 节点都彻底宕机系统就无法对外提供服务了对应的分区会彻底不可用。
在实际配置中可以根据不同的业务场景选择不同的方案。
