kafka 复制集——概念模型

背景

在读完kafka官方文档,kafka设计里的消息交付语义一章后,给我的第一印象是内容很抽象,于是草拟和总结了给个副标题,并把相关内容进行了归类;有些生涩的句子,尽量用大白话和举例进行说明,并加入了总结。 英文链接:kafka.apache.org/documentati...

kafka 复制集的作用

kafka 复制集,是kafka 中间件 "服务高可用" ,"数据高可靠" 的基石。复制集,背后的思想,还是利用了冗余来提高 服务的可用性和数据的可靠性。

(PS:从业多年,在生产环境经历了集群中一台broker停机,且还能让生产者和消费者无感切换,并且数据不丢的经历,只有一次。kafka中间件服务不可用和数据不丢失的情况,在实际的生产环境里, 发生的概率其实挺低的;如果kafka集群经常发生上面的情况,要么是使用姿势不对,要么是broker端的设置有问题。)

kafka 复制集在任何情况下,都能保证服务高可用,数据高可靠吗?

我的回答是,否定的。不要神话"服务高可用","数据高可靠"。所谓的高可用,高可靠,都是有一定的前提条件的。

kafka稳定运行依赖底层的网络,依赖宿主机,也依赖电力,更依赖自身运行环境。连阿里云都宕了,还要求我 全部部署在上面的kafka提供服务,除非是提供了kafka的混合云部署。

所以:kafka 数据的高可靠和不丢失,除了依赖自身的硬件和软件因素,还需要靠复制集(冗余)来保证的。它高可靠和数据不丢失的前提(抛开那些硬件和软件因素)是:只要还有ISR的复制集,就能保证数据不会丢失,并且是可靠的。 (PS:mysql 数据的高可靠和不丢失;主要是靠数据存储到磁盘上来进行保证的。它高可靠和数据不丢失的前提是:磁盘不坏,mysql是能保证数据不丢失的。

redis 虽然提供了数据不丢失的选型;但我想没人去用吧,我们用redis 主要还是看中了它飞快的读取速度,而一般不会用它当做持久化存储。所以存储在redis里的数据, 一般是不保证数据的高可靠和不丢失的。)

主从,主分区(leader partiion) ,跟随者分区(follower paritiion),

主从

kafka 服务节点(broker节点)并没有主从之分,主从的概念是针对topic下的某个partition。对于存储的单位,宏观上来说就是分区,通过分区散落在各个节点的方式的不同,可以组合出各种各样的架构图。 1个主题,3个分区,3个副本分区的架构图

主分区

图中绿色部分为 主分区。kafka生产端只会往leader分区发送数据,消费端只会往leader分区消费数据

follower分区

图中浅蓝色部分为 follower分区。follwer分区,在主分区的broker能提供服务时,不对外提供读写能力,只会从leader分区拉取数据,尽量保证自身数据和leader保持同步。

这种非传统(主机维度的主备)方式的主从设计,理论上可让集群中的每台机器都能对外,提供读写能力,并且尽量发挥出每台机器的计算能力和存储能力。

同步复制集(ISR);Unclean leader

ISR(in sync replica):

处于同步状态的分区。一个follower分区,如果和leader 分区上的数据,保持同步,则称为ISR分区。

非ISR分区:

由于broker端的处理能力,机器的不同,或者网络的原因等,并不是所有的follower分区,都能赶上leader 分区的数据。如果某些follwer 分区落后leader 分区的数据太多,则broker会标记该分区为非ISR分区。

Unclean leader:

当leader分区所在broker不能提供服务的时候,kafka会把ISR中的分区,选择一个出来做为leader分区。如果运气不好 ISR中的分区,也都宕了,让非ISR中的分区,成为了leader分区,我们就称为Unclean leader;因为这样的分区选择为leader分区对外提供服务,意味这存储在broker上的最新消息,已经丢失了。

Kafka对数据丢失的保证是基于至少一个保持同步的follwer分区。如果复制分区的所有节点都失效,则此保证不再有效。当所有复制分区都失效时,一个实用的系统需要做一些合理的事情。如果你运气不好,发生了这种情况,那么有两种选择:

  • 等待ISR中的一个复制副本复活,并选择此复制副本作为领导者(希望它仍然拥有所有数据)
  • 选择第一个复活的复制副本(不一定在ISR中)作为领导者

这是可用性和一致性之间的一个简单折衷。

默认情况下,从0.11.0.0版本开始,Kafka选择第一种策略,并倾向于等待一致的副本。如果不想要数据的一致性,则可以配置unclan.leader.election.enable为true,选择可用性优先(请慎重选择true,则意味这broker上的数据,有丢失的可能)。

总结

  • kafka高可用和数据高可靠,是靠复制集来保证的;背后的思想是对于数据和服务的冗余来实现的
  • kafka 是个分布式队列,主要是指队列的主题上的分区是分布式的
  • 分区有leader分区和follower分区,只有leader分区对 生产者和消费者提供读写服务。
  • 和leader保持数据同步的分区叫做ISR分区,如果follower分区同步的数据落后了leader分区则叫做非ISR分区
相关推荐
故图11 小时前
全字段 INSERT IGNORE:大约 70 行零日期,把证照列表加载打崩
后端
花涧鹤11 小时前
学完分支和循环一脸茫然?我写了个扫雷,把它们全串起来了
前端
Json____11 小时前
用 FastAPI + Vue3 打造一套健身私教课预约管理系统
后端·fastapi·it学习·wwwoop.com
aibo86030811 小时前
基于 Spring Boot + Vue3 的博物馆藏品管理系统设计与实现
java·spring boot·后端
苍何11 小时前
Codex+Obsidian,多平台同步,一键分发,太香了!
后端
fanruitian11 小时前
python 进程 线程
java·前端·python
ZoeLandia11 小时前
React03:useState 与不可变更新
前端·react.js·typescript·react
zzu123zsw11 小时前
把条件校验收敛到枚举接口:Spring Boot 统一断言模式与零污染异常切面工程化
java·spring boot·后端·架构设计
蒲公英内测分发12 小时前
智能手表卖出去后,包装、说明书和官网里的 App 下载入口怎么统一?
前端·人工智能·测试工具·智能家居·智能硬件·智能手表
溪语流沙12 小时前
【Web全栈进阶】监控与告警:线上系统的“体检报告”
前端·vue.js·python·fastapi