kafka-1.kafka初始,架构模型,角色功能梳理

kafka

初始

在一个可持续增长的系统当中,随着业务增大,并发增大,单机队列就会出现单机问题,性能问题。这个时候就出现了分布式的应用,去分摊这些压力。
还是那句老话,目前什么分布式架构都逃脱不了AKF法则,而kafka里面的概念也有点像akf

AKF立方体也叫做scala cube,AKF 把系统扩展分为以下三个维度:

X 轴:直接水平复制应用进程来扩展系统。
Y 轴:将功能拆分出来扩展系统。
Z 轴:基于用户信息扩展系统。

而kafka的维度:

x 轴解决的是单点问题,是高可用的,
y 轴解决的是业务划分的,
z 轴解决的是分片、分治的。

在这里插入图片描述

  • Y轴
    Y轴是业务划分,比如用户行为,广告推荐拆成不同的队列,不同的业务生产和消费都互不影响,每个节点只需要关注自己的东西,资源的利用率就比较高,而kafka里面的topic跟他挺像的。
    假设说我的行为日志存在某个 topic 中,如果我的日志量太大了,如果全部存放在一个节点(中的一个进程)上的话,工作起来 IO 上会受限,而且单看自己它会有一个性能瓶颈。那怎么解决这个性能瓶颈,当我们已经进行过业务拆分之后,怎么再进行更细粒度的拆分,这时候就是我们的 partition。在一个 topic 下,会有多个 partition。
    在同一个topic下面有多个 partition说的,
    在这里插入图片描述

topic 是逻辑概念,partition 是最后物理的对应,一个 topic 下面有 partition 1,2,3…

  • Z 轴
    z 轴应该如何实现?要规划好整个数据路由,将无关的数据放在不同的 partition 中,这样我们就达到了一个后续无关数据的并行度。
    无关的数据是可以并行计算的,如果有关的话,我们会需要在他们之间加上一个分布式锁,或者通过 log id 等方式去保证他们的顺序性,这样会变得很慢,所谓的并发最终还会退化为串行。所以我们希望将并行最大化,将无关的数据分散到不同的分区里,以追求并发、并行处理,有关联的数据,一定要按照原有顺序发送到同一个分区里。
  • X 轴
    这个 x 轴什么意思,x 轴做的是可靠性的保证。现在通过 y 轴和 z 轴,将这些消息打散到不同的分区了,实现的是计算的并行,提升了性能,但是这个时候,如果某一个分区消失了,挂掉了,这时候你堆积的消息会丢失,这时候需要我们给它做副本。在做副本的时候,我们横向走下这个过程。
    无论 redis 也好,kafka 也好, 你像纯内存的 redis,它必须有一个持久化,他会认为磁盘是自己可靠性的来源,如果不在单机的维度,而是看集群的维度的话,单物理节点可能也会丢失,会挂,这时候为了解决节点的问题,我们还需要网络的维度提供可靠性,那 redis 就会有单机的持久化、网络的持久化,基于网络的主从复制集群。那他的主从复制集群就来自于它的 x 轴。其实 kafka 也一样,kafka 分区的数据会持久化到磁盘当中去,而且利用顺序读写这种高性能的磁盘 IO,x轴一般是出主机的、异地的备份,因为如果将全量备份放在同一个节点上意义不大。
    x 轴的拆分会比较容易出现数据一致性、数据的同步问题,会有一系列分布式集群下的解决方案,比如 mysql 会有读写分离的策略,为了解决一致性和复杂性上的痛点,kafka 做了一个决策就是只允许在主片上增删改,从片只允许读。

在这里插入图片描述

由单机到分布式,或者说由传统到中间件,基本都是按照这个思路来设计的我们用到的各种分布式中间件的实现,和 AKF 这一侧是有必然的这么一个参照和关联的关系的。
这些都是方法论,来推导出 kafka 中有 topic,partition,有序性的这些概念,然后我们再把有序性做一个延伸:下面我们来讲 offset
我们知道,分区内部是有序的(纯队列),分区外部是无序的,那这个顺序是怎么得到的?我们用 partition1 做一个简单的描述。假设我们的上游发来三个消息,msg 1,2,3,这三个消息会按照接收的顺序存在 kafka 队列中。当消费者来消费的时候,每个消费者会维护一个自己消费到的位置,也就是 offset。

上面的例子中,只有一个 topic 和这个 topic 下的两个 partition,实际上企业中会有很多个 topic,每个业务下都会有很多 topic,每个 topic 下会有几百个 partition,如何去管理这些分布式的东西的一致性?在经验中,主从是管理成本最低的,它的协调成本会比主主要低,这样会引发一系列分布式协调的问题,包括选主,包括如何保证数据的一致性,常用的解决方案有 zookeeper,或者 etcd。那我们的 kafka 会依赖 zookeeper,主要是依赖它的分布式协调,不过要注意千万不要把 zookeeper 当做是分布式存储来使用。

kafka 对 zookeeper 的依赖

kafka 的 broker 依赖于 zookeeper

  • 使用 zk 存储 broker 的元数据,将 broker 当做是一个进程。
  • 使用到 zk 的选举机制

在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值