首页
找靠谱产品
找解决方案
找靠谱公司
找案例
找对的人
专家智库
悬赏任务
SAAS
ToB门户
了解全球最新的ToB事件
论坛
潜水/灌水快乐,沉淀知识,认识更多同行。
ToB圈子
加入IT圈,遇到更多同好之人。
微博
Follow
记录
Doing
博客
Blog
文库
业界最专业的IT文库,上传资料也可以赚钱
下载
分享
Share
排行榜
Ranklist
相册
Album
应用中心
qidao123.com ToB IT社区-企服评测·应用市场
»
论坛
›
大数据
›
数据仓库与分析
›
Kafka高可用性原理深度解析
返回列表
发新帖
Kafka高可用性原理深度解析
[复制链接]
发表于 2024-12-2 15:55:31
|
显示全部楼层
|
阅读模式
在分布式系统中,高可用(High Availability, HA)是指系统在面对硬件故障、网络分区、软件崩溃等异常情况时,仍能继续提供服务的本领。对于消息队列系统而言,高可用性尤为重要,因为它通常作为数据流通的中枢,任何中断都可能导致数据丢失或服务不可用。
Apache Kafka,作为一个分布式流处置处罚平台,其高可用机制是其焦点特性之一,确保了即使在部门节点失效的情况下,消息的产生和消费仍然可以持续举行。
Kafka的高可用机制重要依赖于以下几个关键组件和原理:
副本机制
Kafka的每个分区(Partition)都有多个副本,这些副本分布在差别的
服务器
(Broker)上。其中一个副本被选举为向导者(Leader),处置处罚全部的读写操作。其余的副本称为追随者(Follower),它们从 Leader 那里同步数据。
如果 Leader 发生故障,Kafka会从 Follower 中选举出新的 Leader ,继续提供服务。
ISR机制
Leader 维护了一个动态的 ISR,含义是和 Leader 保持同步的副本集合(Leader + Follower),如果Follower长时间没有向Leader发送通讯请求或同步数据,该Follower就会被踢出 ISR,该时间由 replica.lag.time.max.ms
配置
,默认是 30s。
只有ISR中的副本才有资格成为新的向导者。
ACK机制
生产者发送的消息中包罗acks字段,该字段代表Leader应答生产者前Leader收到的应答数。
【acks = 0】:生产者发送过来的数据,不必要等待数据落盘应答。
【数据可靠性】:丢数。
【acks = 1】:生产者发送过来的数据,Leader 收到后就应答。
【数据可靠性】:丢数。
【acks = -1】:生产者发送过来的数据,Leader 和 ISR队列内里全部的节点收到后再应答。
【数据可靠性】:丢数。
这里为啥丢数呢?
如果分区副本设置为 1 个,大概 ISR 里应答的最小副本数目(min.insync.replicas)设置为 1,就和 acks = 1 的效果是一样的,仍有丢数风险。
数据完全可靠条件:ACK 级别设置为-1 + 分区副本大于便是2 + ISR 应答的最小副本数目大于便是2
故障规复机制
首先必要在集群全部Broker中选出一个Controller,负责各Partition的Leader选举以及Replica的重新分配;
当出现Leader故障后,Controller会将Leader/Follower的变动关照到需为此作出相应的Broker;
Kafka使用ZooKeeper
存储
Broker、Topic等状态数据,Kafka集群中的Controller和Broker会在ZooKeeper指定节点上注册Watcher(事件监听器),以便在特定事件触发时,由ZooKeeper将事件关照到对应Broker。
broker
当Broker发生故障后,由Controller负责选举受影响Partition的新Leader并关照到相关Broker
当Broker出现故障与ZooKeeper断开毗连后,该Broker在ZooKeeper对应的znode会主动被删除,ZooKeeper会触发Controller注册在该节点的Watcher;
Controller从ZooKeeper的/brokers/ids节点上获取宕机Broker上的全部Partition;
Controller再从ZooKeeper的/brokers/topics获取全部Partition当前的ISR;
对于宕机Broker是Leader的Partition,Controller从ISR中选择幸存的Broker作为新Leader;
controller
集群中的Controller也会出现故障,因此Kafka让全部Broker都在ZooKeeper的Controller节点/kafka/controller上注册一个Watcher;
Controller发生故障时对应的Controller临时节点会主动删除,此时注册在其上的Watcher会被触发,全部活着的Broker都会去竞选成为新的Controller(即创建新的Controller节点,由ZooKeeper保证只会有一个创建乐成)
竞选乐成者即为新的Controller
总结
Kafka通过复制机制、ISR机制、Controller机制和故障检测转移等多种机制来保证数据的可靠性和高可用性,确保数据能够
安全
可靠地传输和
存储
。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有账号?
立即注册
×
回复
使用道具
举报
返回列表
浏览过的版块
物联网
人工智能
虚拟化与私有云
前端开发
网络安全
Oracle
SQL-Server
医疗.卫生
DevOps与敏捷开发
尚未崩坏
+ 我要发帖
登录后关闭弹窗
登录参与点评抽奖 加入IT实名职场社区
去登录
微信订阅号
微信服务号
微信客服(加群)
H5
小程序
快速回复
返回顶部
返回列表