当前位置：首页 > news >正文

kafka基本思路即概念

news 2025/8/25 9:42:36

首先我们在讲消息队列之前，我们需要了解一下Pub/Sub模式，即他是什么，为什么需要Pub/Sub模型。
首先Pub/Sub是什么：发布者不知道接收者是谁，接收者不关心发布者是谁，他们和broker(中间分发人)共同制定主题(topic)，接收者只关心主题。比如我是书店的老板(broker)，我对书店的内容进行管理，发布者(pub)就相当于报刊，他们写消息给我，不关心谁收。接收者(sub)就相当于来这读书的，他通过topic来找自己需要的报刊。那么回到消息队列，为什么他不用普通的队列模式，而使用Pub/Sub的形式来管理数据的传输呢？
让我们来思考队列形式，对于一个队列，他可以有多个producer，可以有多个consumer，但是单个的队列一般只能执行一种能力，比如一个消息队列可以管理商品信息的流动，但是他只能关注一个，而对于其他的信息，比如订单信息，他就需要再开一个消息队列。那么各个服务之间的关系就会变得很乱，对于管理也很困难。

矛盾点	单机直连“队列”	中心化消息队列
连接数	O(n²) 随节点数爆炸	O(n) 只连 Broker
拓扑复杂度	肉眼不可读	一张星型图
扩容/下线	改所有上游代码	只改订阅关系
可靠性	进程挂即丢	持久化、副本、重试
功能扩展	每加一种下游就改代码	直接新增消费组
那么我们需要对队列内容进行集中管理，所以使用了Pub/Sub的形式来降低复杂度。下游提供服务后，上游只需要通过订阅的形式，具体的找通过broker进行，这样对队列集中进行管理，谁要用哪个就给他对应的内容。这样不仅实现了解耦，又可以实现很方便的拓展。来看几张图。
点对点模式：

随着业务发展的点对点模式：
在这里插入图片描述

使用Pub/Sub模式管理的样子：
在这里插入图片描述

那么来看kafka消息队列，他的核心思想也是这个东西。来看他有哪些概念

Messages and batches
Schemas
Topics and partitions
Producers and consumers
Broker and Cluster
Multiple Cluster

Messages and batches

这里的message就是我们所说的消息嘛，他的构成为消息头+消息体，或者说key+value，可以把这一个结构式为对应的message，对于key的一个简单算法就是通过一致性哈希来找到对应的分区，当然这里的head和计网的head类似，可以有很多数据，对应有很多功能。
这里的batch呢，由于我刚做完cs144 lab0，所以对batch印象很深，我们都知道，数据的传输需要一些额外的消耗，比如数据从内存写入磁盘，就有CPU开销，IO开销，磁盘寻址开销。所以OS对于一次操作，会以batch的形式批量写入一批数据，这样就减少了多次写入带来的额外开销。对于网络也是如此，他的开销主要是头部元信息，以及CPU系统调用的开销。所以kafka以batch的形式批量写入message，这就是用了batch的思想。同时，大量的batch会带来延迟，所以这是吞吐量和延迟之间的权衡。

Schemas

这里的schema主要是对兼容性的一大处理，对于普通的结构比如json或者xml，但是对于不同schemas的版本来说，他们无法兼容。那么兼容性主要用在哪里呢？当然是版本变更了，比如v1只有一个字段，但是v2有两个字段，那么处理v1的consumer就要对应变更以处理v2新增的字段，这会导致严重的耦合。所以我们这里的兼容主要是考虑能否用 旧的规则解析新的内容。以此带来的数据一致性也是很重要的部分。

Topics and Partitions

kafka中不同的消息类型被分为不同的Topics，最简单的对topics的理解就是类似于一张数据表，一张数据表被分为很多的Partitions，数据以Append-only的形式追加到分区中，由于一个Topics有多个分区，Kafka 只能保证在一个分区（Partition）内部，消息是严格按照你发送的顺序存储和消费的。但是，如果一个主题（Topic）有多个分区，那么这些分区之间的消息顺序是无法保证的。这里的分区也可以分布在不同的服务器中，意味着他支持水平拓展，这里分区就是一个一个的消息队列嘛。

Consumer and Producer

Producer发送具体的Message到特定的topic中，且通常Producer不考虑其具体发到哪个分区，并且一般发送的信息都是均衡的。在某些情况下，生产者会将消息定向到特定分区。即使用一些特定的方法让消息发送到对应特定的分区。
Consumer读取数据，他可以订阅一个或者多个topics，并且读取对应的消息。Consumer通过跟踪offset来跟踪他消费到哪个message了。这里的offset是message的元数据中的一位，kafka会帮我们来添加offset，每个message都有特定的分区。通过offset来防止数据消耗错乱。同时，可以有多个consumer来共同消耗一个topic中的messgae，一个consumer可以对应一个或多个partition，所以这里consumer也可以水平拓展以增加消耗的速度。这里就有类似集群的概念了，当一个consumer挂掉的时候，其他的consumer就可以顶上去。
在这里插入图片描述

broker and cluster

一个单独的kafka服务器被称为broker(中间人，代理商)，他获取producer的消息，然后给message配备offset，他也有把消息持久化的功能，同时，他也可以给consumer提供consumer需要的信息。那么broker也可以去集群化，他们其中有个大哥(controller)，他的功能有监视其他broker是否寄掉，给特定的broker划分他需要管控的分区，管控特定的分区的broker被称为他的leader，一个分区也可能被分给多个broker，这里也是可靠性的体现，即主从复制。所有的consumer 和 producer必须先去连接broker，才可以去操作里边的分区。
在这里插入图片描述