【kafka学习笔记】 第二天--kafka的基本概念

460 阅读5分钟

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

kafka的消息架构

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

主题层

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

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

image.png

值得注意的是,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.png

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

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

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

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

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

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

消息层

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

总结

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

下文是我自己的理解,不喜轻喷:

  • broker,简单的理解,一个节点就是一个broker,大多数时候一台服务器一个节点。
  • topic,逻辑概念,用于业务隔离,给消费者订阅,生产者发布。
  • partition,真正存放消息的地方,单partition中的消息是顺序的。通常一个盘一个partition,最大化读写优势。
  • 组合起来大概就是一台机器上(broker1),A硬盘存储topic1的partition0 + topic2的partition0 ;然后B硬盘存储topic1的partition1 + topic2的partition1 。

为了高可用:

  • 首先我们需要冗余备份,每个partition最好有2个以上的副本,其中带头大哥就是leader,跟着的小弟就是follower。大哥前面跑,接受消息和发送消息,小弟后面追,追不上的可能就会被抛弃再同步一个小弟。(从“in sync replicas”(ISR)列表中删除)。
  • 大哥挂了,跟的最紧的小弟成为大哥, 如果都一样紧,就选举,由zookeeper决定。

为了使用:

  • 发布消息的叫producer,读取消息的叫consumer。
  • 消息在partition中的位置叫offest,消费者读的位置也叫offest。前者是不变的,叫分区位移或者绝对位移;后者是消费者自己决定要从哪里读,记录读到哪里,也叫消费者位移或者相对位移。其实就是书的页码和你的书签。
  • 通常生产者是很快的,只用写一条数据进去就好了,而消费者需要处理业务逻辑,肯定慢很多,所以就加入了消费者组,一个人打不过就一群人打,逻辑上他们就是一个人。
  • 消费者里面加入人或者有人挂了,都会触发重平衡,请记住这个名字,它是kafka最大的诟病。

image.png

image.png

好了,今天就说到这里,下一篇我们开始实战和慢慢了解使用中的坑。如果你喜欢的话帮忙点赞一下,你的支持是我最大的动力。