【kafka学习笔记】kafka的基本概念

在了解了背景知识后,我们来整体看一下kafka的基本概念,这里不做深入讲解,只是初步了解一下。

kafka的消息架构

注意这里不是设计的架构,只是为了方便理解,脑补的三层架构。从代码的实现来看,kafka其实就一层,不像MySQL分了服务层、引擎层之类的。

主题层

首先是主题层,Topic(主题),比如用户消息,命名为'user_message';支付消息,命名为'pay_message'。两者互不干扰,等于是两条道。

注意这里的Topic是逻辑概念,落到硬件上,应该叫partition(分区),为了提升吞吐量,kafka将一个主题分成了多个区,就像MongoDB 和 Elasticsearch 中的 Sharding、HBase 中的 Region,这是分布式的前提。

image

值得注意的是,kafka只保证单个partition上的顺序。谈到顺序,我们了解一下offest,它标记了消费者在这个partiotion上读到了哪一条。

那么我们想要顺序消费,也要提升消费速度,怎么办?

  • 如果两个消费者同时消费同一个topic下的同一个partition,很显然,他们会重复消费。因为每个消费者的offest是独立保存的。
  • 如果我们分成两个partition,假设topic的数据是123456, 采用随机分配的策略,partition1上的可能是135,2上面是246,消费者A读取1,B读取2,这样就不会重复消费了,但是如果A的速度很快,可能A都到5了,B的2还没读完。这就导致了乱序消费。
  • 很简单,在上面的方案中,我们将随机分配改成哈希分配,从业务层将一个业务逻辑的消息发送到同一个partition上,比如用户ID。如果你的运气足够不好,可能会出现一个partition消息多,另一个少的情况。

好了,回顾下, topic,partition,offest。

分区层

在实际应用中, 我们往往将partition分配在不同的磁盘上,利用多磁盘来增加读写效率。但是既然是分布式,必然需要多个机器,而一个机器,我们常常称为一个broker(节点)

image

多节点不一定要再不同的机器上,只是我们之所以需要多节点就是为了防止意外宕机,如果都在同一台上,一死就全死了,毫无意义。

每个broker都有一套冗余数据,也叫做 repliaction(副本)。(天天网游里面下副本,今天终于知道副本是啥了吧。其实网游之所以有副本,就是为了防止玩家都涌入一个机器,在大家进入副本的时候,就切换到一个新的机器上了,和其他副本互不干扰。)

那么如果我们有三个节点,客户端怎么知道需要连接哪个呢?这就引入了两个概念,leader(领导者)follower(跟随者)。对了,还有个管家,叫zookeeper,它负责管理所有broker的IP地址,是否存活,然后怎么选取领导者,怎么换领导者。这中间的算法,我们后面再细细讲。

总之,zookeeper会选取leader,然后生产者和消费者只和leader交互。那么follower做啥?就是跟着跑,把leader的消息不断拉到本地,准备有一天等领导挂了自己成为新的领导。

(这里和MySQL不一样,MySQL的从库还负责给客户端读。)

好了,回顾下, broker,replication,leader,follower。

消息层

这一层主要是存储信息和消费者的offest。值得注意的是,消息是可以压缩的,上一篇也提到了,这样可以大大减少网络带宽。但是具体细节后面再说。

总结

kafka的陌生词汇还是挺多的,自己在脑海中多过两遍,总整体,到部分,有个基本概念就好,后面谈到的时候能更好地理解。

image
image

你可能感兴趣的:(【kafka学习笔记】kafka的基本概念)