Kafka内核中的分布式机制实现是怎样的

Kafka内核中的分布式机制实现是怎样的，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

一个Topic中的所有数据分布式的存储在kafka集群的所有机器(broker)上，以分区(partition)的的形式进行数据存储;每个分区允许存在备份数据/备份分区(存储在同一kafka集群的其它broker上的分区)

每个数据分区在Kafka集群中存在一个broker节点上的分区叫做leader，存储在其它broker上的备份分区叫做followers;只有leader节点负责该分区的数据读写操作，followers节点作为leader节点的热备节点，从leader节点备份数据;当leader节点挂掉的时候，followers节点中会有一个节点变成leader节点，重新提供服务

Kafka集群的Partition的leader和followers切换依赖Zookeeper

Kafka分布式保证的第一个特性就是：Kafka的Replication

Kafka的Replication指的是Partition的复制，一个Partition的所有分区中只有一个分区是leader节点，其它分区是follower节点。

Replication对Kafka的吞吐率有一定的影响，但是极大的增强了可用性

Follower节点会定时的从leader节点上获取增量数据，一个活跃的follower节点必须满足一下两个条件：

1. 所有的节点必须维护和zookeeper的连接(通过zk的heartbeat实现)

2. follower必须能够及时的将leader上的writing复制过来，不能“落后太多”;
“落后太多”由参数{replica.lag.time.max.ms}和{replica.lag.max.messages}决定

Kafka分布式保证的第二个特性就是：Kafka Leader Election

Kafka提供了一个in-sync
replicas(ISR)来确保Kafka的Leader选举，ISR是一个保存分区node的集合，如果一个node宕机了或数据“落后太多”，leader会将该node节点从ISR中移除，只有ISR中的follower节点才有可能成为leader节点

Leader节点的切换基于Zookeeper的Watcher机制，当leader节点宕机的时候，其他ISR中的follower节点会竞争的在zk中创建一个文件目录(只会有一个follower节点创建成功)，创建成功的follower节点成为leader节点

看完上述内容，你们掌握Kafka内核中的分布式机制实现是怎样的的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！